[WG-UMA] Notes from 23 Sep 2011 ad hoc session to discuss OpenID Connect integration
Eve Maler
Regarding issue #2 and OpenID Connect integration:
The requester app only has to "get the requesting user (natural person) to the AM" (redirect), and then the OpenID Connect flow can happen between the AM-as-OpenID-Connect-RP and any arbitrary OpenID Connect OP. When the AM gets the claims it needs, it can return the requesting user to its previously scheduled session at the requesting app. So why do we even need a claim format keyword in the AM's XRD metadata to advertise what types of claims it handles? If we do need one, it should be called "openid" (to match OpenID Connect's own OAuth scope string).
An AM that is OpenID Connect-enabled (whether we need an XRD advertisement of this or not) needs to commit to this profile of OpenID Connect:
* It is prepared to serve as an OpenID Connect Relying Party (which is synonymous in many respects with an OAuth client)
* It supports at least the OAuth authorization code flow as enabled by OpenID Connect (which would require either dynamic registration or pre-established trust having gotten client credential from the OP)
* It is prepared to handle delivery of any of the predefined/reserved claims defined in the OpenID Connect spec
(How to handle extension claims that are OpenID Connect-compatible? They may have a registry; can we point to that?)
The AM, after getting an authorization code from the OP in the usual OAuth fashion, would turn it in along with its client credentials to get back an ID token, which just asserts the user's (possibly transient and pseudonymous) ID/handle and some session info, and an access token that the AM can then use (possibly along with a refresh token), in combination with the ID/handle just gotten, for further claims discovery and provisioning.
We may need such an advertisement in the case where there's a requesting "legal person" (such as a company) trying to get to a resource with an autonomously operated web service (no interactive user session). But in this case, would OpenID Connect ever be used? This scenario involves no human and no session. Note that this scenario also could be abused by cross-site scripting (XSS). This circumstance should cut out as many redirects as possible. It's more like the implicit OAuth flow that can accept a proactively supplied SAML or JWT assertion from the requesting side.
Maybe OpenID Connect *could* be used for this with a sort of implicit flow, but the state check would fail. It's a hack whose problem is inherited from OAuth. Then again, it could be a useful optimization to push all claims-handling into an OpenID Connect model, for interop simplicity and choice limitation.
For any claims that are volatile, such as current geolocation, the AM will have to keep state of the claims it's gotten and whether, according to its own opinion, the claim might have expired. Any reprompting of the requesting user will be driven by the AM's "authorization expiration strategy". This will affect the validity periods of permissions, access tokens, and refresh tokens that it issues requesters.
(We need to add Domenico to the spec!)
Regarding issue #18:
We're fine with adding http://docs.kantarainitiative.org/uma/ to the suffixes we've already got, such as 1.0/host_token_uri.
Eve will do some initial edits of the spec to incorporate all these tentative decisions, and we'll try to get consensus around all of it next Thursday.
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
- The XRD metadata (UMA Section 2.1.1, slightly misnamed "AM Endpoints") is a useful place for an AM to declare what UMA options it supports, even if it's not strictly useful for requester apps to know which claim formats the AM supports. Should we still have the AM declare its supported options (claim_formats in particular) as a conformance advertisement strategy?
- Dynamic client registration of the host comes into play in UMA Section 2.2. I looked at the OpenID Connect-favored version of dyn reg and it's VERY simple. It also accounts for client secret refreshing. Is there any reason we can't point to this normatively/optionally? Should we still point to our own spec anymore?
- Here's a suggestion for how to structure UMA Section 3.5 to accommodate the OpenID Connect option.
3.5: Top-level description of the portions of the flow that actually involve the requester app.
3.5.1: Description of what to do when the requester app is driven by a human: it has to redirect the human to the AM.
3.5.1.1: Description of how to comply with the XRD metadata "openid" keyword (see notes from the ad hoc meeting below for details).
3.5.1.x: Any other claim format options we build into the UMA core spec (maybe none).
3.5.1.n: Finally, an explanation of how others can extend UMA to support other claim formats.
3.5.2: Description of what to do when the request app is autonomous (a web service client) -- no good answers for this yet, but we did think about it a bit in the notes below!
Questions about OpenID Connect compliance of the UMA AM:
- Is Basic Client Profile enough, or should we require the AM to be "smarter"? E.g., to support the code flow, we'd need to point to full OpenID Connect, not just the BCP.
- Do we need to take a look at iso29115 authentication methods and somehow profile those down?
- We should explicitly mention the reserved claims as listed in BCP Section 4.2, Table 1. And we have to explain how other claims can be supported.
Talk to y'all soon,
Eve