[WG-UMA] Agenda for UMA focus call 2010-12-21
Eve Maler
All are welcome! Maximum running time is two hours, as I've got a hard stop then. We'll use our usual line "C":
• Skype line "C": +9900827042954214
• US: +1-201-793-9022 | Room Code: 295-4214
Lucy Lynch mentioned to me that piratepad.net is a more stable substitute for openetherpad.com, so I've started the following pad to work in:
http://piratepad.net/uma-scope
If we nail that topic and find we have time to move to JSON tokens and claims 2.0 matters, we can create another pad dynamically.
(Today I'll also send out an agenda for our special Wednesday WG call...)
Eve
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
Eve Maler
(Apologies to Alam for cutting him off at the end of the call!)
Following is a dump of the pirate pad, just in case. :-) Let's treat these as the notes for the focus call. I hope to put together a spec proposal for "solving scope" before tomorrow's call, based on all of the below...
Eve
http://mrtopf.clprojects.net/uma/draft-uma-resource-reg.html
Need to codify that the action IDs that the host registers at the AM (step 1) are literally the action ID strings that the requester must use in requesting access at the AM (step 2). No namespace or escaping tricks; the string match must be exact in order for access ultimately to be successful. It's a "lingua franca" among all three parties.
There are two possible ways that the requester can show up asking for the right kind of access to the right stuff. Either the host can register something with the AM that the requester gets associated with (referral resource), or the host can tell the requester to convey the information to the AM directly (referral parameter).
The referral resource method requires out-of-band host-AM communication but keeps the resource set ID opaque to the requester.
The resource parameter method is less "chatty" but exposes the resource set ID to the requester. (We have already recommended that resource set IDs be obscured to avoid privacy-destroying leakage of PII.)
The notion of "token upgrading" looks like it will be important. However, it gets complicated, because the set of constraints to apply to a whole bunch of pairs of RSID+AIDs ("scopes"?) could be multifarious. Likely a requester's access token would accumulate "powers" (access rights) over time if it access for increased access.
Today our core spec requires that the host ask the AM in real time for token validation. Technically, the approach to scoped tokens that we're starting to take doesn't require outsourced validation, as long as the access token can carry a literal (if protected) version of the RSID+AIDs pairs that the token applies to. This is where the JSON token work could come in.
OAuth WRAP had a big interoperability hole when it came to scoping tokens. Our resource sets may be a practical means of filling that hole.
Paul asserts: If there are bearer tokens (host validates token itself), you should use scope (put it inside the token), and if there aren't bearer tokens (host outsources token validation to AM), you should not use scope (no point putting it in the token). Eve agrees. This accords with the parenthetical remark in the last requirement bullet below.
Paul further asserts: The "scope" parameter in OAuth is currently incapable of handling the full power of what we need. Instead, it should be a "scope reference": a pointer to a "scope resource" which could be much longer. Eve isn't sure. Today, OAuth's scope parameter can be a list of space-separated scopes. Paul is concerned about the length of HTTP headers if we have "scope strings" that have to be much longer (e.g., a concatentation, of some sort, of a resource set ID and a list of action IDs). If we needed to solve for length problems, Eve suggests we could use .../host/{hostid}/scope/{scopeid} as a place to cache scope descriptions. Paul is thinking that the AM would be the one creating this, and it wouldn't even have to bother doing this in the case where the host is outsourcing token validation (because the process of mapping to a scope is entirely internal to the AM).
If we approached scope in this way, then we would have a very neat little scope string (the scope ID) to use in the OAuth "scope" parameter ecosystem whenever UMA needs to use that ecosystem.
The OAuth 2.0 world still has the problem of revocation of access with bearer tokens (where resource servers validate tokens themselves, without going back to the authorization server to check them). OAuth 1.0 didn't have this problem because each resource server was its own authorization server, and it didn't have bearer tokens.
We need to look into how tokens can upgrade (or even downgrade) their scope, in practical terms. What is current practice in the OAuth world? Are there any specs, even draft specs, for this? We hope George can guide us on this; Eve recalls previous discussions about draconian vs. loose methods of allowing "old" less-powerful tokens to work.
We suspect that the right host error response to an access token that "isn't good enough" (not enough scope or whatever) is 403 - Forbidden vs. 401 - Unauthorized. That can cause the requester to go back to the AM and fix the situation.
(Eve sent the following thoughts to the InfoSharing group recently:)
OAuth has an "access token" mechanism for allowing an requester to gain access to a protected resource. There's a two-level expiration system. If an access token expires, it might be renewable through a longer-lived refresh token, which is mostly just a security technique. But if there was no refresh token issued or if it too has expired (something the user can control by telling the issuer unilaterally to revoke access), the requester has to go back and do everything it originally did to get the access token the first time.
In basic OAuth, going back and doing this is relatively trivial, but in UMA's extension of OAuth it might require presenting "claims". Claims are the way UMA makes a requesting party promise adherence to a contract offered by the user. So if the user changes their policy (e.g., updates the required agreement) at their authorization manager, it could trigger a requirement to come back and sign on to the newly updated information sharing agreement the next time the seller/shipper wants access to the user's current contact info.
Requirements:
• The authorizing user needs to be presented with a user interface that clearly indicates what resources and actions are available when they're setting and mapping authorization constraints at the AM. [RREG - DONE]
• The AM therefore needs to acquire from the host some description of resources and actions to be protected, which includes enough information to display to the authorizing user. [RREG - DONE]
• The requester needs to know what actions are possible on the resource it is trying to access. This requirement is considered out of scope for UMA; it is anticipated that host API documentation needs to pick up the slack. [?]
• It must not be possible for the requester to be exposed to in-the-clear versions of identifiers for resources in case they compromise the authorizing user's privacy. For example, a protected set of resources might usefully but compromisingly be described as "racy photos from beach vacation". It is assumed that the host already has access to such a privacy-sensitive description and that the nature of the host-AM trust relationship forged by the authorizing user allows the AM to see this description as well. [RREG - DONE]
• The AM needs to be told the relevant resource set, in host-described terms, that corresponds to the resource the requester is seeking access to so that it can assess the requesting party's request for an access token against the correct authorization constraints. [?]
• The host therefore needs to tell the requester the relevant resource set -- and no more, for privacy reasons -- when the requester attempts access at the host and fails, so that the requester can convey it to the AM. [?]
• The host needs to be able to validate that a requester's attempt at access in step 3, accompanied by an access token, matches the resource set and action set for which that access token was granted. [?]
• The AM therefore needs to associate each requester access token with a resource set and action set. (Currently the UMA core protocol defines a run-time method for the host to ask the AM to confirm this match. An alternative solution that meets the requirement would be for the access token to securely contain this information.) [?]
Protocol flow impact:
Step 1 (or anytime thereafter?)
- *Host registers scopes with AM [RREG - DONE]
Step 2
- Requester attempts protected resource access at host, allowing host to infer potential suitable scope(s)
- *Host redirects requester to AM with info about what scope(s) to ask for (needs to be secured somehow?)
- *Requester conveys desired scope(s) in approaching AM
- AM uses desired scope info to match applicable policy (hmm, did we account for multiple scopes here?)
Step 3
- Requester attempts access, this time with token, allowing host to infer required suitable scope(s)
Case 1: Assuming outsourced token validation and true PDP/PEP access management model:
- *Host conveys token to AM, provising acceptable resource set IDs that would match the resource against which access is being attempted and concrete action ID of action being attempted, to ask for validation (full authorization decision request)
- *Assuming token is valid for any of the resource set IDs that the host listed and for the action ID listed, AM returns YES answer - otherwise, NO answer
- Host allows or denies access
(This doesn't need the {scopeid} idea.)
Case 2: Assuming outsourced token validation and hybrid access management model:
- *Host conveys token to AM for validation and to ask for the set of scopes applicable to that token
- *AM validates that the token is still good (not expired) and returns the list of scopes associated with the token
- Host allows or denies access as appropriate
With this method, Host can now potentially cache that knowledge for later (local) use. Also, with this option, the host can do lazy (vs. eager) mapping of the actual access attempt against the valid scopes, and both the host and the AM seem to have less "work to do". This method does need the {scopeid} idea, but it's not baked into the token.
Case 3: Assuming PKI token, with external scope references:
... (depends on JSON token stuff)
Case 4: Assuming PKI token, with scope completely encapsulated in token:
... (depends on JSON token stuff)
Scope description JSON structure:
Note that we specifically mean an "UMA scope" to encompass one or more sets of permissions, each of which could be seen as an atomic "OAuth scope". In UMA, a scope ID would be a string that could be used in place of an OAuth scope string, but it would be an aggregation, not atomic.
We are anticipating that the AM would create these as resources under .../host/{hostid}/scope/, with a {scopeid} on the end that matches the _id found in-band in the description. This {scopeid} would be useful in Cases 2-4.
{
"scope": {
"_id": string,
"permissions": [
{
"resourceSetId": string,
"actions": [ string, ... ]
}, ...
]