UMA telecon 2011-09-29

Date and Time

• WG telecon on Thursday, 29 Sep 2011, at 9-10am PT (time chart)
• Skype line "C": +9900827042954214
  • US: +1-201-793-9022 (other int'l numbers) | Room Code: 295-4214

Agenda

• Roll call
• Approve minutes of 2011-09-22 meeting
• Action item review
  • FAQ status
  • Trust Model status
    • Implications for Measuring the Elements of Trust?
    • Implications for Levels of Assurance etc.?
• Planning for F2F at Kantara plenary meeting on Oct 20
  • No regular WG telecon that day
  • Build agenda for Dervla to publish
• Discuss OpenID Connect integration proposals for Core Section 3.5
  • Discuss issue #2 in this light
  • Try to close #18
• Discuss OAuth 2.0 progress and changes
• AOB

Attendees

As of 22 Aug 2011, quorum is 6 of 10.

1. Catalano, Domenico
2. D'Agostino, Salvatore
3. Fletcher, George
4. Maler, Eve
5. Morrow, Susan
6. Szpot, Jacek
7. Wray, Frank

Non-voting participants:

• Mohammad, Alam

Minutes

New AI summary

• Frank, Sal: Examine loci of LOA/LOP/LOC implications in the Trust Model doc. (targeted for F2F meeting)

Roll call

Quorum was reached.

Approve minutes of 2011-09-22 meeting

Minutes of 2011-09-22 meeting APPROVED.

Action item review

• FAQ status

It continues to be fleshed out.

• Trust Model status

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.

• No regular WG telecon that day
• Build agenda for Dervla to publish

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:

• Self-asserted claims (in a "weak" form, in that the asserter is just the "bearer" of/participant in the AM session, and you're not uniquely and testably in possession of some identity). This has strength that's roughly equivalent to "browse-wrap" (when someone browses to a site and uses it, perhaps unaware that they're bound by terms of service that are linked from the home page). Persistent cookies strengthen this a bit.

• Verified claims. Email addresses and phone numbers are the likeliest to be useful to requesting parties, to AMs that need to register accounts for new requesting parties, and to authorizing users who need to make reasonable access control policies. These, too, could be "pseudonymous" vs. being associated with a particular globally uniquely identifiable session participant.

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.

Next Meetings

• WG telecon on Thursday, 6 Oct 2011, at 9-10am PT (time chart)
• WG telecon on Thursday, 13 Oct 2011, at 9-10am PT (time chart)
• WG F2F on Thursday, 20 Oct 2011, at 1-5pm PT (time chart) in Redwood City, CA, USA
• WG telecon on Thursday, 27 Oct 2011, at 1-5pm PT (time chart)
• NOTE: Daylight saving ends Oct 30 in UK and Nov 6 in US; beware of "summertime skew"