UMA telecon 2013-04-11

UMA telecon 2013-04-11

Date and Time

  • Focus meeting on Thursday, Apr 11, at 9am PT (time chart) - Maciej is chair pro tem
    • Skype: +99051000000481
    • US: +1-805-309-2350 (other international dial-in lines available) | Room Code: 178-2540

Agenda

  • Action item review
  • Discuss UMA+OpenID Connect optimization opportunities – see HIE ad hoc notes (subject line: "Notes from ad hoc meeting 2013-04-05 on HIE scenario") as latest starting point
  • AOB

Minutes

Action item review

Susan points out a visual paradigm called cladistics that shows the evolution of species (and, analogously, the evolution of other things). Maybe use this for showing "scope-grained authorization" and UMA's place in it. Eve can use this for her standard slide deck.

Keith's AI: GLUU will provide access to their server stack; GPII (Global Public Inclusive Infrastructure) has officially endorsed the use case and a pilot implementation. Basically Gluu is making a donation to the Scalable Privacy project.

UMA vis a vis XDI; HIE use cases

Adrian is heavily involved in user policy, and trying to boil it down. You need to have patient identity (non-licensed persons in the system) straight before you can talk about consent, so that you know who consented to what. Doing this heuristically is a bit of a mess. UMA doesn't dictate policy expression, though we anticipate that each deployment profile will specify what policy-setting AS's need to support; this is to support claims-gathering and other needs. Authorization and non-repudiation are separate aspects. When a patient ID is changed for whatever reason, how do you continue to correlate this with all existing authorizations, and inform all those who may be impacted? This is akin to what happens when a credit card gets compromised. It needs to be revoked and various parties informed, but the person behind it is still the same.

Thomas has been hearing virtually the same issue from people wanting to set up a business center last week! Would a "core identity" that has a random string for external-facing identification that may change but is cryptographically bound to the same identity help? An email address doesn't make a great universal, persistent identifier because it can change. Keith likes to think of a credential set. He authenticates into some domain, but they link this to some internal representation.

Andrew is leading an exercise in the IAWG to look at the credential vs. identity issuance question. The government of Canada is working on this.

Discuss UMA+OpenID Connect optimization opportunities

Eve shared an early version of a slide deck that visually shows different optimizations.

One thing UMA adds on top of classic OAuth scenarios is the as_uri parameter that allows a client to visit an RS directly and then discover which AS is protecting that resource. RFC 6750, the bearer token spec, is where you get responses from the RS about the client's presentation of tokens. It's largely undefined. The last Error Code section mentions that an error code shouldn't be produced if the client doesn't include a token in its access request (though a missing parameter could get a 400 - Missing Request). But it doesn't say where you go to remedy the situation. OpenID Connect similarly assumes a visit to the IdP first. So this is an optimization opportunity that has nothing to do with collocation, but rather, with initiation of flow. So we should account for this in our scenarios.

Attendees

  • Eve
  • Susan
  • Andrew
  • Keith
  • Alam
  • Riccardo
  • Adrian
  • Thomas
  • George
  • Jeff

Next Meetings

  • Focus meeting on Thursday, Apr 18, at 9am PT (time chart) - Eve regrets - Maciej will chair
  • All-hands meeting on Thursday, Apr 25, at 9am PT (time chart) - Eve regrets - Maciej will chair