In today's legal subgroup call, we spent some time discussing which trust relationships are in our purview to "define" with model clauses. Adrian proposed a name for one of them.It seems like a great idea to name the trust relationships we're responsible for, partly as a shorthand for ourselves but also definitely useful for our "customers".(I also wonder if there's a conundrum here -- or maybe it's an easily solved one -- in that UMA builds up some two-party relationships into complex three-party relationships. Do we care? We have previously said that our clauses would all be two-party, with preconditions, so maybe it's as simple as that.)In order to make progress prior to next week's call, can we enumerate and try to name the relationships in email? I made a partial list of them in the notes. Here's an attempt at a more complete one in rough order of UMA flow, with our new terminology as best as I can apply it, and also with some naming proposals/discussion. (Some are "offstage" wrt our work, meaning we're not responsible for these agreements.)
- Resource Subject - Grantor if they are different
- This is "offstage"
- RSO - ASO
- Technical artifact that represents it: issuance of the client ID by the AS
- Name proposal ("brute force" :-): "Protection API client agreement"?
- Grantor - ASO
- This actually exists prior to bringing in any specific RS connections; it's the inherent reason for the service.
- Name proposal: "Authorization services agreement"?
- Grantor - RSO
- Any agreement a user might have with an online service might be "offstage" until the connection with the AS comes into the picture, either because of the ecosystem at large (prior arrangement) or because there's a moment where the AS and RS get sewn together with a protection API token (dynamic in some fashion)
- Adrian has proposed "resource registration agreement"; I think I favor "Resource Protection Agreement", because it should cover not just the phase 1/resource registration but also phases 2 and 3/all the respecting-the-token stuff
- Client Operator - ASO
- Technical artifact that represents it: issuance of the client ID by the AS
- Name proposal: "Authorization API client agreement"?
- Note that the Client Operator is not Bob, but the Person that created the client software or runs the client service
- "Requesting Party" (for now) - Client Operator
- This is "offstage"
- "Requesting Party" (for now) - RSO
- This is "offstage"
- "Requesting Party" (for now) - ASO
- Any agreement a user might have with the AS as some other kind of online service might be "offstage" until the connection for the purpose of it being an AS comes into the picture, either because of the ecosystem at large (prior arrangement) or because there's a moment where the AS and RqP get sewn together with an authorization API token (dynamic in some fashion)
- Name proposal: "resource authorization agreement" to be parallel with my proposal above, and in keeping with the API names
- Grantor - "Requesting Party" (for now)
- This is the end-to-end trust relationship UMA really exists to make happen! :-)
- Perhaps fine-grained legal agreements here could be captured as reciprocal consent receipts?
- Name proposal: "resource sharing agreement" or "resource access agreement"
Adrian
If we can get on the same page about this stuff, does it make sense to publish a short paper explaining it for external readers? It would be a great artifact, particularly as we're getting close to our "end of Q1" deadline to present external reviewers with something to review.Notice that throughout, there's a legal context at which we're operating, and a corresponding technical context that it seems useful to refer to but probably only non-normatively. How should we handle that? Should we put it in "Comments" in our model definitions?
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma