UMA telecon 2011-09-22
Date and Time
As of 22 Aug 2011, quorum is 6 of 10.
New AI summary
Quorum was reached.
Approve minutes of 2011-09-15 meeting
Minutes of 2011-09-15 meeting APPROVED.
Action item review
Eve Maler re-elected to the chair role by acclamation.
2012 Kantara budget proposal status
The LC has recommended our requests to the BoT.
Core protocol issues in GitHub
A new web sequence diagram from Domenico is available, matching the latest OpenID Connect specs.
The interaction shown is a sub-sequence for when a requester is asking for access to some protected resource.
The interaction between the UMA AM and the OpenID Connect AS is entirely governed by OpenID Connect. Can we just say in our spec, simply, that the UMA AM would be required to be an OpenID Connect client and the requester would be required to have an OpenID Connect-enabled IdP? Or should it be an option? The requester itself isn't doing any of this work; it's only the AM doing the work. The requesting party (assuming a human, using a browser) would get redirected over to the AM; an alternative could be creating a new account or leveraging an existing account at that AM.
This solves George's problem of picture-sharing with his sister! This has been one of our major motivating factors for UMA's design. Unfortunately, the way the web works today, there's going to be a reliance on email addresses in policies. However, this isn't a barrier to using IdPs that don't issue email address (like GMail); IdPs like Facebook offer verified email addresses as attributes, and as a fallback, the AM could offer to register an account for George's sister, and even do an email address verification loop when she registers.
The OpenID spec list folks are currently discussing the question of what claims should be standardized. They're likely to rely on URIs to identify extended claim types. There is a "verified" Boolean value on claims, which is generically valuable. We could perhaps point to OpenID Connect's standard claims as being mandatory to support if OpenID Connect claims are being used. The AS side would have to at least be able to recognize the claim types being asked for, even if it's not willing to hand out that data (like birthdate).
We have a choice about whether to make zero, one, or multiple claim formats mandatory to implement for interop reasons. We also have a choice about whether to make it possible for third parties to extend to new claim formats. We have consensus that we want to enable UMA to be extensible in this respect (e.g., to allow SAML claims etc. for government and enterprise use cases), and we have consensus that we want to list OpenID Connect as one optional claim format – not mandatory for now.
We think that we now have a solution that works all the way through for human requesting parties operating requester apps that are web-hosted (browser-based), even if some flows would be a bit clunky (e.g. asking Georgina to create a new account at the AM) and we need to look at security considerations with the redirects. SMARTAM already does this redirect, so we have some experience here. You can also bind the trusted identity/claims of the requesting party to any self-asserted claims that the AM asks the user for at the point (e.g. promises), to make them more strongly contractually binding.
We would still need to solve the "requester web services" flows and "requesting humans operating native requester apps" flows.
OpenID Connect really does mean to apply this only to authenticated login sessions, not to looking for active permissions (the way UMA uses this mechanism). Should their mechanism be a bit more flexible and generic? And if so, should they look at the UMA approach? Both use a kind of "artifact" approach, in that an opaque code is being dereferenced. But the token's functionality is pretty different. Should the syntaxes align more? That would probably be ideal.
Deferred. We'll compare it to our nascent OpenID Connect integration spec text.
We'll discuss this in the ad hoc.
Is this site useful to you? Please share it!
| | More
Pages in this Space: