...
| Note |
|---|
This |
...
issues list has been superseded by the issues list on GitHub. |
Access token formats (see issue #30)
How to fill in the access token format property in the AM's hostmeta XRD?
Claims formats (solution under way; see issue #2)
How to fill in the claims format format property in the AM's hostmeta XRD?
XRD vs. JRD (see issue #19)
Should JRD be used instead of XRD? in addition to XRD?
...
We will be opportunistic in splitting out any modular features that are requested for use outside a unified UMA context.
Token-getting flows (Closed)
Need to identify specific OAuth flows (and profile them, as necessary) in Step 2 to cover:
...
Paul recommends that this is a matter purely between these two parties. Recommendation APPROVED on 2010-04-08.
Error messages (Closed)
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 around "claims-required", 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 and claims (Closed; see issue #2)
(This relates to the Claims 2.0 signing work, and possibly to the OAuth and OpenID Artifact Binding signing work.)
...
Making some simplifying assumptions, is it likely that Alice intends to share specific kinds of resources with specific other people whose "usernames" at the related requester app sites she already knows? In this case, can can configure the ACL policies with the "right" entries, such that the requester can either use an existing requesting-user session or sign a claim in lightweight fashion on behalf of the requesting user.
Token validation models (Closed)
Several different ideas have been floated:
...
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 (see issue #30)
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?
...
(See also the newest OAuth signing proposals.)
Discovery (some parts solved; also see issue #20)
Needs for various kinds of discovery have come to light:
...
Are we missing any other discovery types?
Resource-oriented scope management (Closed)
Resources are represented differently in different systems. E.g., Flickr has its own system of naming and grouping resources. How can UMA handle all these different systems? What if you want to set the same policy over two sets of photos, one at Flickr and one at Picasa? It's suggested that hosts control exactly the granularity of access to sets of resources – it could inform the AM of every single resource it has, or could tell the AM it has "sets" (groups?) of resources. Policies at the AM can only be applied at the level of granularity that the host has informed it of. However, what if a single resource appears in multiple sets? The host needs to give the requester a description of the scope it needs to ask for. This could be "encrypted", with some label that maps to a struct that the host gave the AM earlier.
Optimizing for "baskets" (see issue #31)
The following issue was discussed on 2010-04-22:
...
George wonders if this is missing an opportunity for truly intuitive and useful optimization on the requester's part when accessing all the things in a basket. Should it be possible for the requester to approach each host/protected resource in a basket with some kind of intermediate token saying that it's asking for access as part of a "basket request", so that it doesn't have to re-qualify over and over at the AM, by (e.g.) presenting the same set of claims? Then again, if inheritance works such that the "strongest" policy (according to whose definition??) is inherited by everything in the basket, that could be valuable.
Policy support (see issue #2 for reserved claims support decisions)
What kinds of policies would an AM support? What sorts of policy engines would they use? The guess is that there would be a core set of claims that would be supported, driving a minimum set of policies. Other kinds of policies, such as time-based ones, would likely be popular too. If real-time token validation is performed, then time-based policies (and auditing) could be really precise; otherwise there would be some variability based on access token validity windows.
Scalability (see budget request #UMA WG B
With a centralized component, what are the problems with scale? How can we test the scalability of real-time token validation? It's likely that every user can only have n login sessions a day, but they may have 10n or 100n data-sharing connections happen on their behalf a day.