Standing agenda for 2019: Work on producing our second legal-business framework report by September, initially focusing the work on use cases that illustrate each of our mappings from business relationships (and changes in those relationships) to UMA technical artifacts.
...
(Notes from the 2015 series were kept in email: 2015-08-0706, 2015-08-14, 2015-08-21, 2015-08-28, 2015-09-04, 2015-09-11, 2015-09-25, 2015-10-02, 2015-10-09, 2015-10-16, 2015-10-23, 2015-10-30, 2015-11-06, 2015-11-20, 2015-12-04, 2015-12-11, 2015-12-18.)
...
"Legal" topics are currently being covered in a separate legal-business framework meeting series. See the UMA calendar for details.
2019-09-10
Attending: Eve, Andi, Nancy, Domenico, Vlad, Cigdem
Our agenda for today: "Start to document the full value and structure of a final "WG draft report" (or is it a spec?) deliverable that we can put together with all this fodder based on our work over the last several months. We had said our deliverable timing would be September... :)"
The value-add of "UMA-biz-legal-relationships" above and beyond "UMA-technical", we think, is that (e.g.) the operator of a service or client, or the RRA or requesting party, can auditably prove what another party needs it to prove regarding a commitment or promise it has made to the other party. And if necessary, if enforcement can't take place at a technical level, it can take place in a court of law as required (because you have audit logs and non-repudiable artifacts to point to). All of these loosely coupled parties need to cooperate and have their interests sufficiently aligned to have selective sharing work. See examples listed in the Sources of liability tension section on the UMA Legal page here.
Which party cares most about changes, additions, and subtractions in the RRA role? The ASO. The PAT is the "thin reed" of technology (a technical artifact) that binds the ro, as, and rs. Is it enough to give us a technical means of controlling lots of biz-legal-relationships scenarios?
We have several sets of scenarios. One is the ro/RRA state diagram. A second could be a rqp/Requesting Agent/Requesting Party state diagram (that doesn't exist yet). A third that doesn't have a diagram yet is where only policies (a non-UMA artifact) change in response to the ro/RRA sharing on the basis of a relationship. Example: Alice wants to share a set of resources with "whoever is in the 'spouse' relationship" with her. If she indicates that no one is now in that relationship, her policies reconfigure and sharing ends. What's attractive is that both Alice and the ASO and RSO(s), by extension, can all know that sharing ended even if it's a big complicated set of resources that was shared. In this third case, is it really in our scope to be talking about these policies? We could say they're out of scope, but some "consent" (could be described as authorization policy and sometimes is) data formats are standardized, e.g. in HL7 (a Consent record) and XACML, and it is sometimes desired to "federate" consent servers, and even though UMA doesn't standardize policy data formats, it's sort of an adjacent use case. It exists on a continuum with UMA use cases. Plus, all three sets of scenarios seem to end up needing to be combinatorial at the end of the day.
Note that HL7 federated consent implies that you have a federated consent server that you can read and interpret. Consent itself is PHI (personal health information). While UMA technically doesn't require policy conditions to be stored at an AS (this is deployment-specific), it does assume policy-setting can happen at the AS; there are numerous examples in the specs throughout. And the privacy considerations in UMA FedAuthz talk about PII involved in resource registration and policy-setting only implicitly ("the authorization server may come to learn a great deal of detail about Alice's health information just so that she can control access by others to that information"). For example, if Alice tells her AS to share all her data except HIV-related data, that exposes that she may have HIV-related data. The HEART profile for OAuth/FHIR tries to protect against assumptions about existence of confidentiality/sensitivity scopes, but it's still hard not to make assumptions.
Just because you can separate the AS and RS, it doesn't mean they're necessarily in separate organizations/domains. Some privacy considerations may not apply in cases where they are run by the same organization.
Let's start drafting collaboratively. A GDoc is a great way to start, following the (Kantara-inflected) RFC style. Andi and Cigdem are willing to jump in on co-authoring with Eve. Nancy is willing to be backup 
after the next two weeks.
AI: Eve: Start a skeleton draft doc for next time.
AI: All: Sort through the next two batches of scenarios and work on the wording we're using in the second scenario batch in our next meeting.
2019-09-03
Attending: Eve, Andi, Domenico, Lisa, Nancy, Peter, Tim, Colin
...
- Agreement that turns a service provider into an RSO (wasn't included in business model report)
- Agreement that turns a service (or app) provider into a CO (wasn't included in business model report)
- Agreement that enables a Person to act on behalf of a Data Subject [which puts them into position to act as a Resource Owner -- otherwise RO=DS]
- Agreement(s) that delegates authorization for an ASO to grant access permissions on behalf of an RO (typically Ts & Cs, privacy notice, EULA...)
- Agreement(s) that delegates authorization for an RSO to manage resources on behalf of an RO (typically Ts & Cs, privacy notice, EULA...)
- Agreement that enables a Person to act on behalf of a Requesting Party [which puts them into position to act as a Requesting Party Agent -- otherwise RqPA=RqP]
- Agreement that delegates access seeking to a CO on behalf of a Requesting Party
- Agreement that delegates permission to know and persist personal data to an ASO on behalf of a Requesting Party
Jim H has started on a CmA version of the model.
...
Arrgh, so close! Tim and Eve will try and wrap up all the remaining comments in the doc by Monday and get the e-ballot out.
2018-01-12
Attending: Eve, Colin, Tim
...