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"

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?

Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl