...
- resource owner: This is the patient (or other data subject), or possibly a person who has special duties to act on her behalf in setting her sharing policies (for example, a legal guardian).
- requesting party: This is the person trying to get access to the data in question. When the resource owner specifies a sharing policy, she indicates her desired requesting parties as the target. (This concept isn't part of OAuth, only UMA.)
- client: This word stands for "client application", some web or mobile app that the requesting party is using to attempt access to the data.
- resource server: This represents the service provider hosting the data to be shared (or protected). A FHIR server could be an example.
- authorization server: This is a special kind of server whose job is to assess and mediate data access requests, on behalf of the resource owner.
Notes on section 4:
\[Together the RqP + UMA AS add a lot of new bredth and capability to the system, compared to OAuth]
Eve has a good slide comparing the two (although somewhat "techy") There are also some points from recent (past 2 month) WG calls that we can
Can we link the different "techy" value up to the reader level can group under the headings: Security, Empowerment, Convenience, Applicability, Scale, - other Availability, Agency, Audibility, Interoperability
Parking Lot
Julie Story - NL will continue to edit
...