...
- Terminology: Resource Owner => Authorizing User
- Terminology: Resource server => Host
- Terminology: Authorization server => Authorization Manager
- Terminology: Client => Requester
- Protocol/trust: The auth and resource servers meet out of band => Host and AM can meet dynamically (using OAuth or UMA!)
- Protocol/trust: The resource server and client meet out of band => Host and Requester can meet dynamically
- Protocol: Authz is binary: you get a token or you don’t => Authz can depend on requester “claims”
- Conceptual: Authz server issues tokens simply if the user delegated authz => User policy dictates token-issuing
- Protocol: Token validation process is unspecified => Host can ask AM to validate token at runtime
We should avoid putting any UMA sessions on Tuesday mid-late afternoon; we should finish them by Tuesday 2pm. We should avoid signing up for the room that has the terrible acoustics.
Any SMART project showstoppers
Maciej feels they don't have any showstoppers right now, because they made some simplifying assumptions. They did find places where they had to invent a solution, and he will let us know what those areas were.
Christian's issues sent to the list
We want to change things up in the spec so that:
- The AM has distinct ways its hostmeta of indicating host- vs. requester-related endpoints
- The host looks up its own endpoints for step 1 in the AM's hostmeta
- The host tells the requester merely what AM protects this resource
- The requester then looks up its own endpoints for step 2 in the AM's hostmeta
In the OAuth meeting next week, Christian suggests that we should bring up the question of how the OAuth resource server informs the client how to find the relevant authorization server endpoints. Currently, it conveys the user delegation endpoint in a WWW-Authenticate header, so we'd be diverging from OAuth if we use the solution outlined above. But the OAuth spec has precious little information about this process so far, so maybe it would benefit from a hostmeta-based discovery flow anyway.
George believes that in the general (that is, UMA) case, it's not always appropriate for the AM to hand the requester a user authorization URL quite yet, since in person-to-person sharing scenarios that endpoint wouldn't be used. OAuth doesn't get into such sharing scenarios, so they're thinking about how to solve things simply. UMA "goes there" and makes things more challenging by "crossing identity providers"!
OAuth in its original three-legged form always has Alice on both ends. OAuth in its slightly newer two-legged form has a client service being issued meaningful credentials ahead of time. In completely dynamic Alice-to-Bob sharing, the actual requester service being used has no meaningful credentials yet.
Christian has proposed that there are certain bedrock facts that need to be known about the requester service in all cases, e.g. for logging. If the requester initially presents to the AM an endpoint at which metadata XRD can be looked up, is this easier than claims for this purpose? and/or is it a good adjunct to claims that are used (optionally) for other more sophisticated purposes?
Another comment we might want to make to OAuth is to recommend an "automated self-registration" flow for autonomous clients, such that the client can be dynamic but its credentials are uniquely identifying (vs. looking up static allocation of credentials as originally proposed by the old OAuth Discovery spec). (This is why, in the old UMA flow based on OAuth V1.0, things were so complicated! We had the host uniquely and persistently meeting the AM outside of any user context, and the requester uniquely and persistently meeting the AM outside out of any host/authz user context.)
So the fact that OAuth V2.0 has no flow that allows there to be no client_id on first approach is something we're having to work around in UMA. Hey, it should it be called the "anonymous client" flow!
Claims 2.0
Domenico will mail out his proposal. The essential/hardest "identity token" thing we have to try and solve is something like this: If GMail signed a claim saying the requesting party is bob@gmail.com, we're likely to believe that they really authenticated him. But what's harder is to ensure that the bearer of this claim didn't mess with/steal it, and it's really still Bob on the other end. (This is what made SAML assertions so hard for SSO. 
) Let's discuss the proposal in email.
Report from legal subteam on progress and next steps
There's another meeting of this subteam on May 31 (note: which is a U.S. holiday). We discussed what practical sorts of things might go wrong in an UMA interaction, such that Alice did something wrong, CopMonkey did something wrong, etc., and someone wants to sue someone else. International (country-crossing) use cases get a lot harder, so we may want to simplify our analysis by assuming a single country within which interactions take place for the moment.
Next Meeting: UMA telecon 2010-05-27
- Day: Thursday, 27 May 2010
- Time: 9:00am-10:30am PST | 12:00-1:30pm EST | 16:00-17:30 UTC (time chart)
- Dial-In:
- Skype: +9900827042954214
- US: +1-201-793-9022 | Room Code: 295-4214 (other local country numbers available on request)