UMA telecon 2013-04-04

Owned by Eve Maler
Last updated: Apr 04, 2013
4 min read

UMA telecon 2013-04-04

Date and Time

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

Agenda

  • Meeting schedule for April: chairs pro tem?
  • Action item review
  • Discuss UMA+OpenID Connect optimization opportunities
  • Comparisons of UMA and...
    • XDI
    • Others
  • Spec revision roadmap
    • What version should implementations target?
    • Constrain backwards-incompatible changes?
    • "Implementer's Draft" stage/concept?
  • AOB

Minutes

Meeting schedule for April: chairs pro tem?

Chairs pro tem found.

Action item review

AI page updated.

The token introspection spec is not yet officially on the OAuth WG docket, but we think the sentiment is "with" it. MITREid's "client-side filter" (Spring security concept) has an implementation for OpenID Connect purposes. MITREid is publishing to Maven Central now!

Discuss UMA+OpenID Connect optimization opportunities

The healthcare connection to this work is evocative. Some of the ABBI players are having an ad hoc meeting tomorrow at, apparently, the same time that the UMA HIE ad hoc discussion is happening! Justin's thoughts are that the Blue Button OAuth work could benefit from the resource set registration spec. See the Endpoint Discovery section for info on the "trust bundle server" concept, which is kind of a meta-AS; they've proposed a "provider discovery" method that could leverage resource set registration. This is reminiscent of Domenico's work on UMA trust establishment between parties, and also InCommon's service metadata and overall trust establishment work. The goal in ABBI is to avoid PKI. The key concept is for a client to be handed a signed JWT. A "registration token" of this sort can be bound to pre-approved trust framework data in a manner that's out of scope. But such a token could be stolen and replayed, so this bootstrapping mechanism still needs to be protected.

Perhaps "resource set registration" is too specific as to its purpose. It could be seen more generally as "resource server/service provider registration". That spec currently has semantics that are specific to resource sets and scopes (OAuth and UMA concepts) in its JSON format definitions, but the API itself is mostly generic. There's a notion of a client class that can be preregistered, and a client instance that needs to register dynamically. A client instance is going to be talking to a variety of providers and get multiple client IDs from them, even though it's a single instance of code.

Consent management is a huge deal in the healthcare world and the ABBI world specifically. As we've discussed before, "consent" is a weak concept. We like to claim we enable doing more!

Comparisons of UMA and XDI

Optimization opportunities:

  1. Alice-to-Alice sharing (vs. Alice-to-Bob) -- could a side-scoped token (OIC construct) be leveraged? This is really about the ID token, not the side-scoped token.
  2. AS is identical to resource owner's IdP -- when combined with #1, could AAT issuance be optimized? This is likely really about the requesting party's IdP (#3) instead, because AAT issuance happens on the requesting party's behalf. So, see below for that. All by itself, this "colocation opportunity" isn't all that exciting; it just helps Alice log in to her AS easily.
  3. AS is identical to requesting party's IdP -- could AAT issuance be optimized and a side-scoped token be leveraged? If Bob's IdP is also Alice's AS, the IdP could a) already be in possession of claims that could satisfy Alice's policy, and b) could be preprovisioned with authorization to serve as his claims client (that's the AAT part) for anything it doesn't yet know.
  4. Resource server is identical to client app (vs. distinct) -- could AAT issuance be optimized?
  5. New one: Alice's RS is an OIC RP of her UMA AS/OIC IdP. (In English: Alice's resource server, say, for her calendar, is a relying party for social sign-in from her OpenID Connect IdP, which also happens to be her UMA authorization server.) This is a compound optimization opportunity (vs. a simple one, where there's only one simplifying assumption). This simplifies getting the PAT.

New language for discussing:

  • Optimization opportunity: Has a simplifying assumption.
  • Simple optimization opportunity: Has one simplifying assumption.
  • Compound optimization opportunity: Has more than one.
  • Optimization juncture: Area that is being simplified, optimized, or removed by virtue of some profiling/extension exercise between UMA and OpenID Connect.
  • Typical optimization junctures: PAT issuance, AAT issuance, RPT issuance, and authorization data association (policy assessment and authorization data association with the RPT).

Spec revision roadmap

Our current habit is to submit drafts to IETF around every three months (e.g., the current I-D is "rev 06"), with incremental drafts published only on the kantarainitiative.org site (named "07a", "07b", etc.), as often as we like. What if we state publicly that our I-Ds are "Implementer's Drafts", and commit to doing them no more often than every three months, and even generate some outreach attention around those? We already keep a list of breaking/major changes; we should highlight those in I-Ds.

Let's plan some outreach/publicity around our next I-D, which will be rev 07, and try to get more implementers to play with it.

AI: Eve and Thomas: Plan rev 07 implementer's draft push.

Attendees

  • Eve
  • Susan
  • Keith
  • Domenico
  • Justin
  • Alam
  • Maciej
  • Lukasz
  • George
  • Thomas

Next Meetings

  • Focus meeting on Thursday, Apr 11, at 9am PT (time chart)
  • 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