UMA telecon 2011-03-24

Date and Time

• WG telecon on Thursday, 24 Mar 2011, at 9-10:30am 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-03-03 and 2011-03-10 meetings
• Action item review
• News from the wider UMA world
  • SMART project progress
  • EEMA conference, upcoming events in Berlin and Munich, IIW
  • Dynamic client registration in the IETF OAuth group and upcoming meeting in Prague
• Reach conclusions on scoped access solution
  • Notes from ad hoc call
• AOB

Attendees

As of 24 Feb 2011 (post-mtg), quorum is 7 of 13.

1. Adams, Trent
2. Bryan, Paul
3. Catalano, Domenico
4. Fletcher, George
5. Machulak, Maciej
6. Maler, Eve
7. Moren, Lukasz

Non-voting participants:

• John Bradley
• Kirk Brown
• Kevin Cox
• Cordny Nederkoorn

Regrets:

• Sal D'Agostino

Minutes

Roll call

Quorum was reached.

Kirk Brown of Talkwheel (formerly of Sun identity management) is interested in frictionless, secure web-based social networking and real-time group collaboration that's accessible on a variety of devices. Talkwheel needs to manage granular and persistent access to, say, a single thread of conversation (vs. Facebook's transient model). Since there's a lot of file sharing and a lot of cross-service coordination needed, UMA is appealing.

Approve minutes of 2011-03-03 and 2011-03-10 meetings

Minutes of 2011-03-03 meeting APPROVED.

Approval of minutes of 2011-03-10 meeting deferred until they can be posted.

News from the wider UMA world

Cordny and Alam both presented on UMA at the EEMA conference last week. There was a fair amount of interest. Cordny connected with the conference organizer and other Kantara folks to explore organizational synergies.

People attending the IETF meetings next week in Prague would ideally like to have an UMA person present our dynamic client registration draft to them, as this problem space is being considered for the charter. No one is available, unfortunately.

Reach conclusions on scoped access solution

• Notes from ad hoc call

We walked through the flowchart. Kirk asks: What about AD access control on a resource? Like maybe Active Directory could provide a trusted claim saying who is attempting access. Paul responds: UMA is orthogonal to additional AM-sourced policies and H-controlled access constraints. Eve's take is that if a person operating the requester can be represented by a tClaim that was generated out of AD, great.

It appears that a single token is in the position of having to represent a particular requesting party, as bound to an AM (and host). This is the only way that a set of n authorization scopes can be usefully associated with it. Thus, the requester already has an unshakeable responsibility to manage the distinguishing of its different users. However, what are the pros and cons for that requesting party to be proven at the token (ABC) stage, vs. the claims (FGHI) stage, that the requesting party is identical to the authorizing user? (This is the long-form explanation of the "always two-legged?" note in the flowchart.)

Binding the requesting party and authorizing user at the token stage means that:

• We'd use the normal OAuth 3L flow in the special case where it's "Alice again", and thus we'd have two alternative flows (token authn vs. identity claim) to do the "same thing" conceptually. The OAuth 2L flow would be used for all non-Alice "autonomous" requesting parties.
• Alice would have to log in to link the identities, but wouldn't be in a position to consent to authorizations because our flow isn't up to the scope-checking point yet.

Binding the requesting party and authorizing user at the claims stage means that:

• We're not reusing 3L OAuth at all, and where we might want to import a login-and-consent flow, we'd at best have to "copy and move" that portion of OAuth and also define a request for a special kind of claim that kicks off this process.
• We're making a "breaking" change to the way UMA implementations have been heading (are we?).

We gained consensus that the token itself represents a unique requesting party/host/AM binding. It's fair to expect requesters to manage this and get a new token whenever one of these elements varies. But we intend to solve for that single token being associated with an arbitrary number of authorization scopes. If we eventually enable the "meaningful token" option (where the token is a JWT stuffed with content), then the pros and cons previously discussed for this choice come into play (see, e.g., these notes), and we'd have to build into the spec a way to turn in the old insufficient token and get a new more-powerful token.

Talkwheel has a use case where Kirk invites all the soccer players on the team to join some resource, by emailing them something. An UMA-specific way of viewing this use case is that Kirk gives his AM a policy that says anyone with a certain private URL or some other shared secret can get access, and then a claim is requested that corresponds to possession of the secret. Obviously this is a lightweight use case, and stronger enterprise-style security might need tClaims.

The current SMART implementation does use OAuth-derived 3L authenticated identity instead of identity claims. In fact, even for Alice-to-Bob use cases, they use the same flow, such that Bob gets provisioned with his own credentials at the AM. It's acknowledged that this is a naive approach; it was chosen for expediency. Users are still finding that a redirect to the AM is confusing anyway. Maciej notes that for purposes of doing things like emailing unique OTPs to groups of potential requesting parties, the AM would ideally need to know the resource's URL so that it could do a complete mailing to those folks.

We will strive to push forward on all these fronts prior to next week's meeting.

Next Meetings

• WG telecon on Thursday, 31 Mar 2011, at 9-10:30am PT (time chart)
• WG telecon on Thursday, 7 Apr 2011, at 9-10:30am PT (time chart)