UMA telecon 2011-06-02

Date and Time

WG telecon on Thursday, 2 Jun 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-05-26 meeting
Action item review
SMARTam.net report
Schedule review: goals for June
Protocol review: core spec review
OpenID Connect/trusted claims review (Domenico material forthcoming)
AOB

Attendees

As of 2 Jun 2011 (pre-mtg), quorum is 6 of 11.

Catalano, Domenico
D'Agostino, Salvatore
Fletcher, George
Hardjono, Thomas
Machulak, Maciej
Maler, Eve
Moren, Lukasz
Morrow, Susan
Wolniak, Maciej

Non-voting:

John Bradley
Kirk Brown
Cordny Nederkoorn

Minutes

New AI summary

Thomas: Recommend times to do a WebEx SMARTam demo with the UMA WG members (not a full webinar).

Roll call

Quorum was reached.

Approve minutes of 2011-05-19 and 2011-05-26 meetings

Minutes of 2011-05-19 and 2011-05-26 meetings APPROVED.

Action item review

2010-11-18-4 Eve Open Capture new user stories in the wiki.
2011-03-02-1 Nat Open Put together JWT-compliant examples of Claims 2.0 and Simple Access Authorization Claims. Pending. Now OBE.
2011-04-07-2 Frank, Kirk Open Match constellations to scoped access diagrams to see what happens. In progress. They'd like to update according to the latest spec.
2011-04-14-1 Maciej, Alam Open Build list of FAQs (both questions and candidate answers) on the wiki. In progress.
2011-05-12-1 Eve Open Check out the possibility of running a new UMA webinar. Target second half of June.
2011-05-12-2 Domenico Open Look into how to contribute Claims 2.0 to the OpenID ABC work. Done.

Kantara has agreed to join the OpenID ABC/Connect Work Group. That group now doesn't have any IPR-related problem reusing work coming from Kantara, since Kantara had to promise not to assert any relevant patents. Thus, the Claims 2.0 work is already under consideration at an appropriate level. The goal is to keep the userinfo endpoint as simple as possible. A simple set of JSON elements will be the default userinfo. Anything else will use an extensible claims architecture, where the claim request looks sort of like a claim.

There's an interesting divergence in how scopes are understood in the OAuth world (a blunt instrument/opaque string), the OpenID ABC/Connect world (a need for fine-grained access to different claims from the exact same userinfo endpoint, which functions as a magic claims discovery endpoint), and the UMA world (a need for access that amounts to RESTfully based access constraints on protected Web resources, which isn't fine-grained enough for this).

SMARTam.net report

The public beta has some new features that will be coming online tomorrow. Thomas tentatively offers to let us use his WebEx account next week to have the SMART team walk us through the app.

Schedule review: goals for June

We'll target June 30 to submit our I-D. Maybe we can also leverage the July/August OpenID Connect testing and interop events being planned.

OpenID Connect/trusted claims review (new Domenico proposal)

This is an integration scenario with UMA claims and OpenID Connect.

The UX wireframes illustrate how in-app authorization policy setting might be accomplished. There would be an AM widget embedded in the host app. This is an optional part of the picture, but interesting nonetheless.

Beyond that, John reports that the vision of OpenID Connect in the UX matches the intent of the OpenID Connect protocol work in general. He notes that they are explicitly adding support for email addresses as OpenID identifiers, along with directed-identity tricks.

Eve suggests it would be useful to highlight our classic "bob@gmail" use case in one of the UX flows, where Alice develops policy ACLs that list email addresses that need to be "verified" as belonging to the requesting party. So Bob could type in bob@email.com at the beginning of the attempted access, and then that unrolls a discovery process that allows for verification of that claim.

This demonstrates UMA's unique value-add: While OpenID (and OpenID Connect) is about a person's relationship to a website mediated by an IdP site, and OAuth is about a person forging a relationship between two apps interacting on their behalf, UMA is about making it possible to allow sharing with a different party (Alice-to-Bob sharing), with the authorizing user not required to be present for the access to happen.

OpenID Connect is hoping to wrap up in the July/August timeframe. Libraries to support it are being worked on. Johnny Bufo at JanRain is working on the rollout. George expresses interest in helping to create open-source libraries. The Newcastle team is interested in contributing. The RP piece isn't complicated; the IdP piece obviously has more moving parts, though optimizing for just a verified email address claim could shorten the timeframe.

Then the next step would be connecting the authorizing user's PoCo groups to the AM. And there's also some trust framework efforts going on so that the major consumer IdPs can act as relying parties for each other.

Protocol review: core spec review

Thomas is away the last week of June on vacation, but otherwise he's around to do editing the rest of the month.

Let's re-review the issues discussed last week:

"Issue 1 (Need to specify options for claim formats in the XRD.) Maciej suggests that we need to provide the name of the supported claim format - i.e. claims2 or something else but not json. JSON would be used just to structure information but tells nothing about the semantics."

Should we list "openidconnect" as the only option for now? If so, should it be mandatory or optional to implement, and for which parties? If a policy allows for "anonymous authorization" (e.g., "must be a citizen of the UK"), then the requesting party would still have to authenticate as a prelude to sharing the necessary claims, but the identifier could simply be the moral equivalent of a transient pseudonym.

What about when the requesting party is a web service that isn't using a true user interface? This is something like a "two-legged" use case. We have some constellations that are specific to this (e.g., sharing your demographic data with InfoUSA, where you yourself don't have a login there). Would OpenID Connect make sense here at all? There's perhaps a way to use it, e.g., in flows meant for smart clients, but it's not optimized for a true web services use case. You could use a signed request that provides claims in the same token. It's a bit like an unsolicited assertion provided in the initial request for authorization.

For now, let's add an optional "openidconnect" claims format to the spec.

"Issue 2 (Need to clarify how the requester's user authorization endpoint would be used in an UMA (vs. an OAuth) fashion for collecting synchronous authorizing user consent in Phase 2, based on a privileged type of claim request.) We're not sure about the specifics of the issue - i.e. "synchronous authorizing user consent". Maciej suggests it resembles the current flow used in the SMART implementation. George has a different view on this vocabulary. We decide to move forward and leave this issue for the time being."

This would get solved "automatically" based on the OpenID Connect discussion we just had in this meeting. If Alice sets up a policy saying that only "alice@gmail.com" (herself!) can get to a particular resource, then we can simply lean on OpenID Connect entirely to solve the Alice-to-Alice sharing problem! George had been wondering if there was a special distinction between synchronous and asynchronous authorizing-user involvement. Indeed, the synchronous case (Alice herself being redirected to log in and consent to the sharing of her verified ID) is an UMA+OpenID Connect matter. By contrast, some sort of "Liberty Interaction Service" style of interaction, where Alice (as authorizing user, not requesting party) sets up a request for the AM to ping her by SMS if anyone comes looking for access, would be a value-add feature provided by the AM software and wouldn't be part of the UMA protocol per se.

Next Meetings

WG telecon on Thursday, 9 Jun 2011, at 9-10:30am PT (time chart)
WG telecon on Thursday, 16 Jun 2011, at 9-10:30am PT (time chart) – Eve regrets
WG telecon on Thursday, 23 Jun 2011, at 9-10:30am PT (time chart)
WG telecon on Thursday, 30 Jun 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

Browser not supported