Below.

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

On Fri, Mar 11, 2016 at 2:08 PM, Adrian Gropper <agropper@healthurl.com> wrote:

For the time being, let's adopt Eve's preference and refer to UMA Phase 1 as a Resource Protection Agreement.

I will graciously accept your temporary terminology concession. :-) Please see Grantor - RSO below for further thoughts...

 

I think we would benefit by adopting the blockchain distinction of "permissioned vs. "permissionless" resource protection patterns. http://insidebitcoins.com/news/barclays-were-experimenting-with-both-permissioned-and-permissionless-blockchains/36008

Permissioned access might imply an offstage trust agreement or federation as a pre-requisite for protection of a specific resource. In our UMA case, permissionless would be dynamic registration of the ASO or the Client.

More comments inline, where I also highlighted the "offstage" when it occurs...

On Fri, Mar 11, 2016 at 3:29 PM, Eve Maler <eve@xmlgrrl.com> wrote:

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"? 

This can be either permissioned or dynamic. If permissioned, then it's "offstage". If dynamic, then it's part of the Resource Protection Agreement.

I don't see why it should be offstage just because it might happen as a big Ts & Cs kind of legal agreement. We are creating model clauses to be "deployed" any which way by legal agreement builders, not just tacked on to an access token messaging flow. I'm using the word "offstage" to mean, literally, out of scope for our group to work on. We can switch to "out of scope" if you like.

For example, look at how Andrew Hughes's project is considering using the output of our work. They are not planning an "UMA-enabled services" deployment, or even an "identity federated services deployment", or even a single "deployment of random services". They are developing an entire trust framework to serve a variety of deployments of online services of all kinds, within which it's known that some of the services will have to do "identity" jobs and some of the services will have to do "access" jobs in order to serve the purpose of delivering high-quality, secure, privacy-sensitive services to people.

We're here just to accelerate the UMA-specific portion of that and let all the other stuff take care of itself.

• 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"?

Why wouldn't this be "offstage"?

It's a good question. My rationale was as supplied above, but maybe I could somewhat echo the same language I put elsewhere: Any agreement a user might have with an online service might be "offstage" until the service's role as an AS comes into the picture. There's no technical artifact in the UMA protocol that correlates to a dynamic moment when "AS-hood" is assigned, unlike with some other service roles, but the role could be taken on by prior arrangement or in some dynamic fashion.

• 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

My point in suggesting the name "resource protection agreement" is to stress, as noted just above, is that it's not just about phase 1. The protection API has three endpoints the RS uses as a client: resource set registration, permission registration, and token introspection. And the RS itself presents an API to the UMA client in which some of its actions are UMA-prescribed. If we want to preserve the RSO's right to avoid liability for refusing to transfer data out of the country given Russia's laws or whatever, that clause has to go somewhere. And since the instructions it's refusing are Alice's instructions, it seems that should go in the Grantor - RSO agreement.

• 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"

I see this as being "offstage". The core value of UMA is to enable delegation to the ASO to the extent it is practical. This UMA delegation adds value to both the RSO and the ASO. Trying to capture this "end-to-end" trust is unnecessary and confusing. This idea of an end-to-end "resource sharing agreement" is what most people call "consent" today and just makes UMA harder to understand and to implement.

I would suggest we replace this last bullet with:

• RSO - ASO
• RSO provides notice to the ASO of the transaction with the Requesting Party.
• Name proposal: "resource access notice"

(I thought you didn't like the word consent?)

We already have RSO - ASO, which is exactly where I am proposing resource protection agreement. This is different. I think we're getting tangled up in the many senses of "delegation" that tend to float around. There are lots of words for what Alice is doing when she uses UMA for what it was designed for: permission, authorization, consent, granting access, sharing, delegation... When I use "delegation" here, I mean:

• YES: Alice's constrainable delegation of access all the way to Bob
• (This is the commonest usage of the term wrt UMA and similar systems; examples include the New Zealand UMA POC closure report, 
• NO: Outsourcing of policy decision-making from the resource server to the authorization server
  
• (Your sense above)
• NO:  Resource Subject-to-Grantor delegation in order for that second Person to handle the first Person's authorization affairs

In fact, the old Binding Obs spec thought up a bunch of things that Bob might need to promise to Alice (see them here), and Alice might need to promise to Bob (see one here). But indeed, is it viable to capture these, given that they're separated by so many intermediaries? How would such an agreement be formed?

[one more note below]

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?

Important unrelated note that I just thought of: The UMA Core spec has a set of "extensibility profiles" that allow pairs of entities to opt out of using the UMA-standardized interfaces (RSO-ASO, Client Operator-ASO, and the offstage RSO-Client Operator) because their trust relationship is so tight or moot as to make the normal communication channel pointless. I'm going to add a GitHub issue so we can consider what impact this might have on our model clauses.