UMA telecon 2011-09-29
Date and Time
As of 22 Aug 2011, quorum is 6 of 10.
New AI summary
Quorum was reached.
Approve minutes of 2011-09-22 meeting
Minutes of 2011-09-22 meeting APPROVED.
Action item review
It continues to be fleshed out.
It's been rewritten and the trust relationships are now named functionally. Can we get to a point where we can positively label the TRs that have LOA/LOP/LOC implications?
Planning for F2F at Kantara plenary meeting on Oct 20
We think the SMART team will be attending, but we're not sure.
Discuss OAuth 2.0 progress and changes
Spec draft 22 has been pushed upward to IESG for review. People are still discussing a few proposed resolutions on the group email list. We don't expect any conforming text to change. Mostly we think that there have been changes to the explanation of client authentication to the server.
Discuss OpenID Connect integration proposals for Core Section 3.5
See this thread of ad hoc meeting notes.
Depending on how a human requesting party authenticated to the requester app, perhaps we could allow for an optimization: a sort of "implicit flow" that lets the requester app pass along an assertion proactively, which would be immediately useful to the AM (as claims requester). This could be a certificate or a SAML assertion or whatever. And this flow would presumably be similar to what a requesting party represented by an autonomous web service would do.
However, it seems reasonable for "UMA 1.0" to have the general fallback position of redirecting a human requesting party to the AM and for the AM to support OpenID Connect as an option for getting trusted claims.
Should we keep the "claim formats" portion of the XRD metadata, even though the requester app doesn't need to know this given our current direction? Eve and Frank are inclined to keep a machine-readable description of AM conformance options. George, Susan, and Sal tend to agree. The alternative is that you have to have a lot of handshaking and fallback activity in the protocol.
We suspect that eventually we will, indeed, need an "authorization code flow" and an "implicit flow" for various combinations of human-driven (browser or native) and autonomously driven requester apps.
The UMA AM (which has to be a web service) is optionally going to be an OpenID Connect RP/client. What simplifying assumptions can be made around it in this role? The OpenID Connect Basic Client Profile isn't sufficient, since the OPs that the AM will need to connect to will want to enforce the code flow for better security in many cases. We think, therefore, that the AM should implement a standard OpenID connect RP. We're inclined not to further profile it down for UMA purposes, so that it can take part in standardized OpenID Connect interop testing.
What about the OpenID connect Dynamic Client Registration spec? Should we use it in preference to our own DynReg proposal? We think we should point to the new one. It's way simpler and better thought out than our old one, and we'd rather put implementers in a position to reuse as much code as possible (as Jacek points out).
Does this option rise to the level of being worth capturing in XRD metadata as a significant conformance option? We suspect so. The overall goal would be to reflect the entire conformance "option tree" in some machine-readable form. We think Cordny will like this as a tester.
What should happen in the absolute rock-bottom fallback case for human-driven requesting parties (human requesting party or human agent of some other requesting party), when either the AM doesn't support OpenID Connect or the person doesn't have an OpenID Connect-enabled identity provider to kick things off? There are two kinds of claims that are plausible in this circumstance:
What's the minimum bar for UMA-conformant AM support? If we require them to create local accounts for requesting parties, that turns them into an IdP of some sort. Maybe we should document best practices around this instead, at most. Our goals should be to encourage implementation, adoption, and ecosystem-strengthening among all of these related technologies. The AM could, if it wants to, support non-OpenID Connect-compliant IdPs, such as Facebook – or "itself" as an IdP.
Is this site useful to you? Please share it!
| | More
Pages in this Space: