...
- (Get on join.me)
- Action item review
- Spec issues review and resolution
- RS=C optimization opportunities
- AOB
Minutes
EIC report-out
Joni reports: At this EIC, there's been significant interest in its progress. Recall that Mario H presented a demo (which was recorded) last year. Perhaps unexpectedly, there's been considerable forward movement in the "Life Management Platform" efforts – it's the European incarnation of the personal cloud concept. They have a lot of transportation use cases, e.g. booking tickets for trains etc. There was an LMP track at the conference. In every session of that track, UMA was referenced as a potential core component for how to administer an LMP. Joni will make introductions to make sure that we follow up.
Domenico is preparing a blog entry on LMPs, which will publish next week.
Eve wonders: Is there a distinction with a difference between LMPs and personal clouds? We're not sure. Andrew notes that LMPs have been evolving along with VRM (Doc was at EIC) and personal clouds. (Eve points to this old blog post showing UMA's relevance to the intersection of all of the above, plus enterprise use cases.)
George notes that Drummond was discussing the "respect" angle on all this at IIW. There's delegation at the identity level that needs to be accomplished, at scale. Some people are taking the old OpenID V1.0 idea of personal identity assertion to new heights in a multi-server model. Eve points to Domenico's long history of work around true technical trust on which UMA relationships can be based. George and Sal express confidence that PKI/asymmetric key methods of technical trust may yet find success at scale, given new developments. Eve points to Gluu work on policy management, OpenID Connect-friendly authentication context, and centralized scope access management. Essentially, UMA is already proving that it has the technical underpinnings to support many expressed LMP/PC/VRM use cases. We'd like to take this further by optimizing usage with OpenID Connect in particular (and possibly other technologies such as XDI).
UMAWG Twitter handle
Eve, Sal, and Joni are willing to co-administer the UMAWG handle. We will set this up with the Meshfire tool.
CIS-timeframe plans
Eve has asked Mark Diodati for a room with a capacity of 10. Joni will approach Jeremy with the idea of an NSTIC-affiliated working meeting/summit at CIS and let us know; Eve will write a short abstract to help Joni make the case.
"Implementor's Draft" and interop plans for October/November
In addition to our nascent plans around an interop at the MIT event, Joni notes that there's a workshop being planned for Oct 29-31 in Amsterdam. It's early days for that. It's potentially a joint venture between Kantara, OASIS, and IEEE.
Securing space, securing funds, and doing education/outreach are all things the LC could help with. Eve needs to capture the scope and goals in her note to the LC.
RS=C optimization opportunities
Deferred.
GPII use case
Keith has shared a Cloud4all/GPII architecture overview. The Preferences Server could be a resource server fronting an authorization server. The overall architecture seems kind of heavyweight. However, Keith's pilot work is focusing simply on the needs/preferences data, protecting it, and governing access to it. The matchmaking capability is simply a necessary function given the use case: there needs to be a site/app/device/user capabilities intersection that's non-empty. Keith also reports that he has now logged in to the Gluu stack that Mike is making available for experimentation, and he's forwarded info about a Gluu webinar in their role as InCommon affiliate.
UMA open source
Publishing under an Apache license is free for anyone to do. But if you want to get code into one of the official projects, we're not sure. Joni notes that Kantara can help with the former process, using the Apache CLA. Andrew notes that Allan Foster is likely a good source of info.
Registration-time constraints on the resource server
Eve briefly described Alan Karp's request for UMA to specify tighter constraints on the resource server not to register any resource that Alice doesn't have a right to control access to. This is perhaps related to further downstream sharing on Bob's part, and perhaps to Domenico's suggestion around "right to be forgotten" handling. Let's add this to the issues list and discuss more fully next time; Eve will send out more info. This may also relate to the RS=C scenario.
Attendees
As of 16 May 2013, quorum is 6 of 10.
- Eve
- Maciej
- Keith
- George
- Domenico
- Sal
Non-voting participants:
- Andrew
- Joni
Regrets:
...
Action item review
Done. See that page for details.
Spec issues review and resolution
Issue 79: no comments right now.
Issue 81:
- The 2xx codes are explained here. OAuth Bearer mentions 2XX in passing, but just seems to assume that this all rides on HTTP, so naturally 2xx is appropriate for success. UMA only mentions 200 OK "in passing" (though it's probably technically normative) in the introduction to its Section 3. It's a simple fix to change to 2xx Success. Since success is defined wholly by the API you're calling, we can keep this very light. Should we say instead that "... the resource server responds with whatever its application-specific interface defines as a success response"? (George notes that something like this came up in the Token Revocation conversation.) Thomas should make that change.
- as_uri: We think there was some history here around lopping off the http: scheme, but we can't think why. You could use a URN or a proprietary scheme too. If we were going to require RSs and clients to verify that they're getting config data over https, it could be argued to leave off the scheme. But if we want to be friendly to, e.g., testing with localhost:, then having a whole string makes sense. Eve argues to keep the string whole, including the protocol, so as not to overspecify. Agreed.
- Requested permissions: Can we add non-normative text explaining that the resource owner (subject) associated with this resource set ID (object) and scope or scopes (verbs) comes implicitly from the PAT? Eve suggests "The resource server MUST provide its valid PAT in order to get access to this endpoint; this PAT implicitly identifies the resource owner ("subject") to which the permission applies." Agreed.
AI: Thomas: Implement issue 81. (Part of his standing AIs.)
Issue 82: George muses: If the AAT is just a standard OAuth 2 token (which is true), it can be revoked, it can be invalidated, etc. We believe that this proposal constitutes an interesting OpenID Connect-, LOA-, and authn context-friendly profile that inserts itself at the AAT juncture (which, as the "head" of the requesting party and client authentication chain, seems appropriate). Gluu's use case is related to enterprise needs – thus the "initial AAT issuance through web services", i.e., silently since the human resource owner agent doesn't have the right to withhold consent to claims-sharing, as this is simply part of their employment contract.
OpenID Connect has some global optional parameters to represent some light authentication context, e.g., to handle LOA. Gluu's proposed solution is finer-grained. The UMA AS and the requesting party's IdP/AP would need to establish trust at the AAT level in order to start to gather authentication context (outside of the claims system) as well as any claims. Domenico's older banking use-case work did have an element of LOA in it. Eve likes that the AAT's tuple doesn't correlate with the RS, and the RS is kept properly out of the policy-assessing equation.
AI: Domenico will share the links to his most recent UX exploration that include LOA types of considerations.
AI: Eve: Ask Mike Schwartz to consider turning the Dynamic Re-Auth of RP proposal into a true UMA profile, referencing the advice in our spec, so that we can begin to catalogue it with others on our wiki (with no favoritism of profiles implied).
RS=C optimization opportunities
Attendees
- Andrew
- Eve
- Maciej
- Domenico
- Sal
- George
- Thomas
- Keith
Next Meetings
- Focus meeting on Thursday, June 13, at 9am PT (time chart)
- Focus meeting on Thursday, June 20, at 9am PT (time chart)
- All-hands meeting on Thursday, June 27, at 9am PT (time chart) - George regrets
- (No meeting Thursday, July 4 because of the US holiday)
- (No meeting – vs. potential F2F/summit during CIS – on Thursday, July 11?)
...