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.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma