[WG-UMA] Current issues list

[Eve Maler]

I hope everyone gets a chance to read through the draft 00 spec carefully. We're trying to keep the issues list at the end of the spec up to date. (We'll probably spin off a separate wiki page to record issues once we start getting any comments in from OAuth community members.)

To help us prioritize, here is my take on the status of the issues. I'm hoping we can tackle the high-priority ones and the easy ones ASAP. If you'd like to weigh in with your opinions on the list ahead of time, or take ownership for proposing solutions for any of these for the group to consider, that would be great.

http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol#anchor15

High-priority:

• ISSUE#14: Need to unify the request for authorization with the providing of claims, so that this can be a single request-response pattern that can loop as required. (Discuss/decide on Jul 7.)
• ISSUE#24: From Lukasz email 6/6/2011: Rev8 Section 4.1: Empty response body? In SAM we return 'resource_id' and 'policy_uri' so that the host can redirect the user to the policy definition page (sharing setting screen) on AM. (Discuss/decide on Jul 7.)

Easy (discuss/decide as many of these on Jul 7 as possible):

• ISSUE#15: If the content-type (of the claims response document) is not recognized by the AM, what happens then? Should be an error from the AM. We need to create an error for this.
• ISSUE#25: From Lukasz email 6/6/2011: Section 4.1 - what happens when a resource (being registered) already exists?
• ISSUE#27: Can Update Resource Set Description API mistakenly overwrite/destroy an existing resource description? (SAME as #25?)
• ISSUE #37: Okay to cache token status as now explained? Do we need to add examples if so?
• ISSUE #38: Does the returned permission ticket need an expiration field?
• ISSUE #39: Examine all MAYs/SHOULDs throughout the spec to see what conformance instructions/levels may be necessary. E.g., in Section 3.1.3, why is the host's 401 Unauthorized response to a requester with an invalid token a SHOULD instead of a MUST? When would it ever do something different? Similarly, Section 3.1.4, why are the host's actions in the case of insufficient permission a SHOULD instead of a MUST? Is it a case of the host deciding to just not respond at all? In Section 3.2, why do we say the requester SHOULD use the client credentials authorization grant type instead of MUST?

Interesting:

• ISSUE#18: Provide commentary on any requirements layered on the forthcoming OAuth security considerations section; discuss UMA-layer implications for more meaningful authentication of requesters/requesting parties; discuss implications of user-mediated AM/host trust model; discuss short-lived token technique for lightweight requester correlation... (Someone want to take this AI?)
• ISSUE#19: More privacy considerations. (Susan AI?)
• ISSUE #33: Should it be possible to have an "implicit resource set" somehow that (in syntactic-sugar fashion) allows permissions to be passed around much as scopes already are passed around in plain OAuth? (Someone want to take this AI?)
• ISSUE#16: Need to profile for specific claims-requested lists and claim responses. (Someone want to take an AI for each of "openid-connect" and "claims2"?)
• ISSUE #35: Consider allowing the host to provide a filter in the token validation request to indicate the particular resource sets/scopes it would find acceptable, so that the AM can provide only permissions that potentially match any of them. This approaches a PDP/PEP model. (Can someone concerned about the eventual size of tokens take this AI?)
• ISSUE #40: MUST the host give access if the requester has suitable permission? (Someone want to take this AI?)
• ISSUE #41: MUST the host register a permission? If it doesn't want to, or doesn't succeed in doing so, MUST it respond to the requester, and if so, should the ticket (and even the am_uri) field be optional? (Someone want to take this AI?)

Other:

• ISSUE#17: Need to say what claims formats are supported. (Can wait for further work until we profile for particular formats already known.)
• ISSUE #36: Okay to use the made-up URI "http://kantarainitiative.org/ns/uma/1.0/..." for labeling the AM endpoints and other identifying URIs? Should these actually resolve to anything? (Waiting for Kantara staff to get back to us.)

Eve

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl