As of 24 Feb 2011 (post-mtg), quorum is 7 of 13.
Non-voting participants:
Regrets:
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.
Minutes of 2011-03-03 meeting APPROVED.
Approval of minutes of 2011-03-10 meeting deferred until they can be posted.
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.
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:
Binding the requesting party and authorizing user at the claims stage means that:
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.