...
- Fridays, 8-9am PT
- Screenshare and audio: http://join.me/findthomas
- UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar
2017-07-28
Attending: Eve, Kathleen, Tim, Bjorn, Mark
(Oops, a bug in the diagram, the sharing scenario labels need to be reversed.)
The nature of the CO’s access to the resource is determined by the TOS between the CO and the RqP, particularly in the case of a human RqP (Individual scenario). The client app will have certain access-getting capabilities, and will represent those to their user. Who is paying whom for what? In the case of an Individual RqP using a client app, quite often the individual downloads a free app (possibly with in-app purchases) or pays for an app (this would be for mobile apps, including those associated with smart devices, or even for desktop apps). In the case of a Legal Person using a client app, more often there won’t be TOS as such but the client will be developed in-house or done as work for hire by a mobile app dev house.
In both cases, an ASO would tend to be in control of which clients they work with because an AS gets to be “picky” about clients -- clients always bring security risks. But different ecosystem pressures can lead ASO’s to be more open or closed. The DirectTrust initial trust bundle (trust framework) was deemed not safe enough so they had to develop a second one. No matter how "dynamic" the process becomes, and the OAuth Dynamic Client Registration protocol is making it quite dynamic, there are reasons for an ASO to potentially want the process to include manual steps, such as lawyers or accountants or other certifiers to get involved. This is precisely where trustmarks and whitelist mechanisms of various sorts are intended to reduce the friction of such manual mechanisms. A client developer could then include a signed assertion in their "SSA" (software statement assertion), which an AS could consume.
The technical artifact we could eventually potentially take advantage of here is something in the SSA for dynamic client registration for UMA certification.
There's a nice older diagram, looking like a train track or puzzle pieces, that shows the various TOS's sticking everything together. What might be better is two train tracks, for the RO and for the RqP, where they build up enough relationships with the RSO/ASO and CO/ASO respectively through the legal/technical artifacts and merge. Ultimately we could show them diverging as the licensing relationship gets torn down. (This would be when we know that we've reached the end of designing the legal framework!)
We agree that our goal is to have the legal framework point to the technical artifacts (e.g. as we did in the old Binding Obs), and this is sufficient for now. Various individual tools in the toolkit will ultimately have technical artifacts point to legal artifacts (e.g. URLs containing hashes of the specific versions of text etc.). This latter approach is all implementation-dependent, and so we don't want to optimize prematurely.
We should try a) connecting the definition of Data Subject to Resource Owner, to justify why to include Data Subject, or otherwise drop Data Subject, and b) drop Requesting Party Agent and include "with the legal authority to seek access" to Requesting Party, or not drop RqPA and figure out how to square the circle. 
See the list below, and deliverable #1 for use cases! That rationalizes the two halves of the licensing end-to-end relationship.
The legal versions of the sharing scenarios should actually look like this:
- Individual-to-self (this is potentially interesting legally because Alice tends not to want to impose onerous licensing controls on herself, only on the CO)
- Individual-to-Individual
- Individual-to-Legal Person (maybe this breaks down along the lines of different business models)
- Individual-to- (do we want to consider "Requesting Party Agent" as a role because of use cases?)
WRT Data Subject, we could treat that as a whole separate mapping exercise: DS, DP, DC. Should we do that separately? A topic for another time.
The ONC Trust Exchange Common Agreement work could potentially point to this work to get to a more dynamic model vs paper-based.
AI: Eve: Reach out to Domenico to get his help on creating new diagrams that drill into these detailed relationships.
2017-07-21
Attending: Eve, Kathleen, Tim
...