...
Compliance with OAuth 2.0
We now know the general shape of (Assigned to Eve)
Eran has begun exposing drafts of his 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
spec. We should begin moving the UMA core protocol spec onto an OAuth 2.0 basis as soon as practicable, and try to stay on top of any changes on a weekly basis.
Modularity
(Assigned to TomH)
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:
...
New vs. existing patterns for getting a token
(Assigned to Maciej)
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
(Assigned to Paul)
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
(Assigned to George)
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
- Continuing the discussion
George has motivated the need for identity tokens in an email thread. The next step is for the group to discuss and validate the need.
Token validation models
(Assigned to Maciej)
Several different ideas have been floated:
...
Which of these are useful to standardize?
Maciej has laid out requirements and considerations in an email thread (and the group discussed the issue a tiny bit on 2010-04-01). The next step is to discuss how our use cases inform our need for a technical solution here.
Signed messages
(Assigned to Paul)
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)??
Paul has made a case that UMA needs no signing of messages in an email thread, and the group further discussed the issue on 2010-04-01. We await more written scenarios from TomH to inform our decision-making here.
Discovery
Needs for various kinds of discovery have come to light:
- The host needs to be introduced to, and to learn about how to trust, a user's chosen AM
- The requester needs to learn what resources it can get at the host
- The requester needs to learn what AM endpoint to go to to get an access token for a desired resource
Step 1 of the UMA protocol is all about discovery type #1 in the general case. The question of token validation as discussed above is about how the host can come to trust the AM, whether at introduction time, access time, or somewhere in between.
The hData scenario involves a model of "trusted discovery" that encompasses type #1 and also type #2. The introduction of the host to the AM involves the extra step of the host registering its own metadata with the discovery service associated with the AM, possibly including a manifest of resources and available scopes of access to them, which then becomes relevant to discovery type #2. Is there interest in standardizing this outside of the UMA core protocol?
Regarding discovery type #2, if the user doesn't directly provision the requester with a resource URL and some notion of possible method/scope of access ("Data Dominatrix"), and doesn't advertise the URL broadly ("Hey, Sailor"), the other possibility is that the requester can discover a list of resources and appropriate scopes at a discovery service or resource catalog (shall we call this "Look Me Up"?). This is the approach mooted in the hData scenario through the requester accessing the discovery service mentioned above. (Note that the notion of scoping mechanisms pervades requester->AM, requester->host, and host->AM actions at various points, as discussed below.)
Regarding discovery type #3, the core protocol spec currently says that "If the requester knows, by whatever means, the access token URL for the AM that is protecting the desired resource without first approaching the host, it MAY proceed directly to that URL" (meaning that the requester doesn't have to discover the AM endpoint only by trying to hit the resource first). Given the new WRAP paradigm we are using, the requester could therefore get an access token to use at a host without ever having approached the host before. This amounts to pre-authorization, which we had rejected before (as "bulk" pre-authorization) in the case where a requester wants access to resources at multiple hosts. Do we see any pitfalls here?
Are we missing any other discovery types?
Resource-oriented scope management
(Assigned to TomH)