.
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.
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.)
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.
...
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.
...
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.
If the client had included an RPT in its failed access attempt, it MAY also provide that RPT in an property in the body.
Example of a request message containing an AAT, an RPT, a permission ticket, and a PCT: ...
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.
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.
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?
Example:
HTTP/1.1 200 OK Content-Type: application/json { "rpt":
"sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv", "pct": "c2F2ZWRjb25zZW50"
}
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).
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.
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?
- 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?
Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl