This is a list of issues we need to burn down in working on the spec(s) (currently just the core protocol). See also the issues listed in the Scenarios and Use Cases document.
Compliance with OAuth 2.0
We now know the general shape of OAuth 2.0, though we should probably wait until Eran's first official draft before editing our own core spec off of WRAP. What changes need to be made? How closely should we track changes in the base OAuth spec?
Modularity
Some UMA features on top of OAuth 2.0 are separable; some seem to be attractive to a wider developer audience even outside the UMA value proposition. Which should be defined in separate specs for greater modularity? Will some pieces be in a position to be submitted to the IETF in the near term, ahead of submitting some other pieces? Some possibilities:
- Dynamic discovery
- Back-channel token validation
- Claims-required mechanism
- Resource-oriented scope management
New vs. existing patterns for getting a token
The Lexicon describes ways that the existing WRAP profiles could be mapped to UMA's needs for a requesting party to participate in getting authorized access. What is the correct mapping? Do we need new and different patterns?
Interactions between refresh tokens and the claims-required flow
Do we have any need or desire to require refresh tokens to be issued in all cases, perhaps due to the positioning of the claims-required request, or is this a matter purely between a requester (client) and AM (authorization server)?
Also, how should the claims-required flow be integrated into the OAuth substrate. We've been asked for input on whether we need new OAuth error messages beyond the HTTP error layer. Do we need a new OAuth error, or an explicit extension point for an UMA error, or no explicit extension point at all for adding our own flow at this point?
Identity tokens
George Fletcher and Praveen Alavilli have mused on how to create "identity tokens" that would represent a particular user online in a generic way. Is this applicable to UMA scenarios in which the authorizing user or the requesting party must be identified? If so, is it useful for us to standardize it in some spec module? See:
- Protecting "discovery" information
- Open identity token
- Open identity token and personal discovery service
Token validation models
Several different ideas have been floated:
Real-time remote validation: This is the option currently in the spec. A token validation URL is treated as a protected resource at the AM, which the host accesses in real time by supplying the requester-presented token and describing the type of access that was attempted (resource and method). This has the advantages of allowing the host to have an extremely lightweight structure, and allowing the AM to keep detailed and accurate records of access attempts for display in analytics etc. It has the disadvantage of Internet-scale performance issues.
Hybrid validation: At their leisure after being introduced in step 1, host asks AM (in an as-yet undefined interaction) to provision it with the means to do accurate local validation (probably the AM's certificate) whenever a requester does present a token. This has the advantage of creating little or no delay in the first validation and no delay in subsequent validations. It has the disadvantage of not, all by itself, allowing the AM to know the exact nature of requester attempts.
If hybrid validation is enabled, its disadvantage could be mitigated by allowing or requiring the host to use the back channel forged in step 1 to provide access logs to the AM on some schedule.
Whether validation is real-time or hybrid, the host could use the back channel to provision the AM on some schedule with protected resource descriptions, such as all the URLs at this host controlled by this authorizing user at this AM, along with "display names" chosen for them at the host. This has the advantages of improving the authorizing user's experience in setting policies and reviewing analytics directly at the AM, and potentially making it easier to offer the feature of letting the user protect different resources at one host with different AMs.
Which of these are useful to standardize?
Signed messages
Does UMA require messages from the requester to the host to be signed in any circumstances, or does it need to ensure that the option is preserved in OAuth, or does it not care (Paul's current contention as discussed on 2010-03-25)?