Re: [WG-UMA] Persisted claims token language

I’m going through the document as it stands in GitHub as well, and there’s a few things I wanted to note. First, the model of the PCT here isn’t what I intended. What I’d said previously was that the PCT could represent a user’s consent (or authorization) along with its primary purpose of optimizing the experience for a client/RqP pair at a particular AS over time. That seems to have been stretched into it representing such an interactive consent at all times, and being strongly tied to that purpose. To clarify what I meant, I see the different tokens and items throughout the UMA protocol being defined, roughly, as follows. RPT (Access Token): represents the right of a client acting on behalf of an RqP to access a resource or set of resources (or set of resource sets) based on policies set by the RO at the AS. This is also known as the “access token” and is returned by the “access_token” value from the token endpoint. RPT(RO, AS, RS, ResSet(s), RqP, Client, Policies, Claims) ticket: represents a transaction between the client and the RS/AS to retrieve an RPT. As such, the ticket is used as the key to the next step of the authorization process at each stage, representing whatever the current state of the multi-step process we’re at. Tickets can be associated with an RS (first stage), then have the client added (when it’s identified at the token endpoint request), then have claims added representing the RqP (when it’s used during claims gathering). Ticket(RS, ResSet, AS, Client, Claims, RqP) PCT: represents a set of claims and interactions between the AS and the RqP/client pair during one authorization process to be used during future authorization processes. This can represent claims gathered interactively or pushed from the client. This can also represent any interactions the AS has with the RqP during this process, including any gathering of consent or authorization in any meaningful way. In short, this represents the sum total of the authorization process that a client went through to get its RPT (or even just trying to get its RPT). It’s intended to be used when this client gets a new RPT for this RqP at this AS, whether or not for the same resource or resource set and possibly for different policies or resource owners alltogether. PCT(AS, Client, Claims, RqP) Refresh Token: Represents the right of a client to get a new access token, either identical or downscoped, without interactively presenting the user (RqP). This is tied to a particular resource set or set of resource sets just as the RPT is. RefreshToken(RO, AS, RS, ResSet(s), RqP, Client, Policies, Claims) PAT: represents the right of a resource server to access the authorization server’s protection API. Which is to say, the RS becomes the client and the AS becomes the RS in this part of the system. The AS is *also* the AS, still, which confuses people. PAT(RO, AS, RS, ResSet(s), Tickets) This all fits back in with the excellent diagram that Domenico posted to the list (copied here). I’ve left of the ID Token my list here as that’s an ancillary process during the claims gathering section of the protocol, but the diagram is still correct on this part. I think most of my disagreements about the text below stem from this miscommunication about the intent of the token. Deeper comments to the text inline:

On Sep 20, 2016, at 10:34 PM, Eve Maler wrote:

We're having trouble with the XML editor, so in lieu of a properly published -02, here is a proposal for some revised PCT language snippets for consideration.

Latest draft is Core 01 https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-01.html.

GENERAL ISSUES/COMMENTS: We're not talking terminology yet, but note that we have a thing called a "claim token", and it maps to something very different from a "persisted claims token". We've previously used "trust elevation" as the generic term on top of claims-gathering, step-up authentication, and whatever extension methods might come along. We've now got a model where claims are pretty much everything. In terms of specification, what's the right phrase? Rhetorically, trust elevation has been pretty useful, but if we switch, we'd just need to find a phrase for claims-something because "claims-gathering" so far has meant the interactive version, vs. "pushing". Claims collection? (Sounds like the insurance business or something.) Note that I've avoided "consent" in favor of "authorization", a la OAuth. It seems to work fine.

Naming things is really hard. I’m a fan of having “claims” in the name of this new token, as I think that it captures what George and I were talking about. In my branch I’ve been using “saved claims token” and keeping the same “SCT” acronym that Eve originally had in the text I branched from, but either of these is equivalent. I agree with the sentiment on the list (and in my other email) that this token does not represent “consent”.

Sec 1.2, Terminology

persisted claims token (PCT) A correlation handle, conveyed from an authorization server to a client and back, representing the interactively gathered authorization of an end-user requesting party during this trust elevation process for persisting any claims pushed and/or interactively gathered for the authorization server's own potential use in future trust elevation processes.

I don’t think the PCT *has* to represent the interactively gathered consent of the RqP, but it *can* represent that consent if the AS gathers it. What it does represent is that this RqP and this client spoke to this AS previously. So how about this for a definition: persisted claims token (PCT) A security token issued by the authorization server to a client which represents by proxy a set of claims previously gathered from that client, either interactively or pushed. The client MAY present the PCT to the AS in lieu of gathering claims again. The PCT MAY be used across multiple RPT requests. The AS MAY interactively gather the authorization [or consent?] of the RqP and associate that gathered authorization [or consent?] with the PCT.

ISSUES: Is "this trust elevation process" clear? Intent is that it means one "run" of the protocol, with as many claims as required in phase 2 to get to phase 3. Should it be "authorization-seeking process" therefore? (This appears in 3.6.3.1 below too.)

Not a fan of “trust elevation process” as that’s a weighted phrase in other protocols. Authorization-seeking doesn’t quite cover the whole thing either though.

Sec 1.3.2, Authorization and Protected Resource Interfaces, UMA Grant, and Requesting Party Token

... The authorization server MAY enable an end-user requesting party to authorize a client to engage in future trust elevation processes in an optimized fashion using the persisted claims token (PCT) option; see Section 3.5.3 for more information about this option. …

This is fine (caveat naming of the process above) but we want to avoid the appearance that the PCT always represents a gathered consent. The server MAY ask the user if they want to issue a token, or it MAY just decide to do so without prompting.

Sec 3.5, Client Seeks Authorization for Access: The UMA Grant

... In order to access a protected resource successfully on the requesting party’s behalf, a client needs to present a valid RPT with sufficient authorization data. The client uses the token endpoint to acquire an RPT and optionally to ask for specific scopes it wants, providing the permission ticket it received from the resource server and optionally providing a persisted claims token (PCT) it received from this authorization server. ...

This works, but with a reference to what the PCT is in another section?

Sec 3.5.1, Client Request to Authorization Server for Requesting Party Token

The client makes a request to the token endpoint by sending the following parameters using the "application/x-www-form-urlencoded" format per [RFC6749] Appendix B with a character encoding of UTF-8 in the HTTP request entity-body:

ticket REQUIRED. The permission ticket. rpt OPTIONAL. If the client had included an RPT in its failed access attempt, it MAY include the same RPT here. claim_tokens OPTIONAL. In circumstances where the client needs to provide requesting party claims to the authorization server, it MAY include this value here. See Section 3.6.2 for more information. pct OPTIONAL. In circumstances where the authorization server returned a PCT previously when returning an RPT, the client MAY include the PCT when including the same RPT here.

This isn’t exactly what I’d intended for the PCT. The language here makes it sound like the PCT is contingent upon the RPT and can only be used when refreshing that same RPT, and I don’t think that’s quite it. The PCT may be issued with the RPT but it’s not dependent upon it. It’s meant to represent the relationship of the AS to the client/RqP entity pairing, across multiple resources. If we want to talk about a way to get a new RPT directly from the client, that’s what a bog-standard OAuth refresh token is for.

If the client had included an RPT in its failed access attempt, it MAY also provide that RPT in an property in the body.

This is fine here, and it’s orthogonal to the PCT.

Example of a request message containing an AAT, an RPT, a permission ticket, and a PCT: …

I think the examples need to be expanded to show different combinations: - Ticket only - Ticket + RPT - Ticket + PCT - Ticket + RPT + PCT And that’s not mentioning refresh token only.

Sec 3.5.3.1, Authorization Server Response to Client on Authorization Success with Persisted Claims Token

The authorization server MAY return a PCT along with an RPT, subsequent to gathering authorization from an end-user requesting party at the interaction endpoint. The authorization server MUST NOT return a PCT if it has not gathered authorization from the requesting party. See Section 3.6.3.1 for more information about gathering this authorization.

As above, I disagree with this statement. While the PCT *can* represent explicit authorization by the RqP, it doesn’t *have* to represent that. What it ultimately represents is that this AS saw this client/RqP combo before and is comfortable telling the client that said client doesn’t need to prove the RqP’s presence or existence again as long as it has the PCT secret.

The PCT is a securely random, unguessable value that is static for the life of any one RPT with which the authorization server initially issued it.

Doesn’t need to be random, does need to be unguessable. Should follow the rules for OAuth access and refresh tokens which have no restrictions on format as long as an attacker can’t manufacture one.

ISSUE: Work to be done: Describe handling of incoming client request for RPT with an SCT in it. Correlate with RPT, ticket, and any claims, add any appropriate error states, and return same SCT back as appropriate. Describe here, or in client request section?

Describe the correlation between tokens in the authorization processing section.

Example:

HTTP/1.1 200 OK Content-Type: application/json { "rpt": "sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv", "pct": "c2F2ZWRjb25zZW50" }

New format based on OAuth’s token endpoint response: { “access_token”: "sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv”, “token_type”: “Bearer”, “pct”: “c2F2ZWRjb25zZW50” } I would even potentially go as far to spell out “pct” here and in the request, but that should be decided once we have a real name. “pct” is a fine placeholder value for the syntax right now.

Sec 3.6.3.1, Authorization Server Gathers Requesting Party Authorization for Persisting Claims

At any time during interactive claims-gathering, the authorization server MAY gather authorization from an end-user requesting party for persisting any claims that are pushed and/or interactively gathered during this trust elevation process for its own potential use in future trust elevation processes. If the authorization server has gathered this authorization, then it MUST generate a PCT to accompany an RPT to represent that authorization (see Section 3.5.3.1 for information on generating and using the PCT).

I disagree with this on several levels. First, it should always be up to the AS whether or not to return a PCT. The normative requirement above has no teeth, as a server implementer is left to decide on their own what “gathering consent” or “gathering authorization” really means. And still, the PCT doesn’t represent the authorization but rather acts as an optimization for the client/RqP pairing. Note here that it’s up to the client to present the right PCT if said client is a multi-user client talking to the same AS, but this is the same requirement that a multi-user client has when dealing with access tokens, refresh tokens, or any other security device. Still, we may want to point that out in the security considerations.

NOTE: In order to manage the claims' persistence, it is likely that an authorization server will need to associate them with an account or profile for the requesting party. However, there is no requirement for the authorization server to present the requesting party with local account registration or authentication options; it could use federated account management techniques such as social sign-in instead.

That’s not true at all. The AS must associate the PCT with the client, but I don’t see anything that requires a sign-in to save the PCT and what it represents. Yes you could associate a PCT with a sign-in to allow an RqP to log back into the AS and manage all of their issued PCTs across various clients (probably not a bad idea, honestly), but that’s not required for the protocol to work.

ISSUES: Here and in 3.5.3.1, I've tried out language that assumes the AS MUST generate the PCT if it gathered the authorization. Does this work? No, as stated above. I was trying to think of how to specify a specific claim to gather to represent authorization, but since -- as we discussed -- it's both gathered and consumed by the AS, does it make sense to make it a formal claim, or can it remain in the squishy realm of "gathered authorization"? Is there value in specifying it as a formal semantic?

I don’t think there’s value in specifying that. An AS that is capable of interactively gathering consent and associating that with a PCT might have a data model for the PCT that looks like this: PCT: - value: <random string> - client_id: <id of the client the PCT was issued to> - presented_claims: [ < list of claims that the client presented either interactively or directly, represented by this PCT > ] - authorization_gathered: < boolean of whether or not the user interactively clicked the “yeah, sure” button > This is all internal to the AS and not part of the spec.That’s kinda what I meant by saying that the authorization is “just another claim”, in that it’s really just something that’s gathered interactively by the AS and represented in the token itself. Could be stored in the “claims” structure above or it could be its own field, entirely up to the AS implementer. Hope this helps clarify things, — Justin

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

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma