UMA telecon 2013-02-28

Date and Time

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

Agenda

• Roll call
• Approval of past minutes
• Action item review
• Sketch elements needed for an "UMA-protected OpenID Connect", including discovery of claim types available through an AS
• AOB

Minutes

Roll call

Quorum was reached.

Approval of past minutes

MOTION: Keith moves: Approve minutes of UMA telecon 2013-01-31 and reading into today's minutes the following past focus meeting: UMA telecon 2013-02-21. APPROVED by unanimous consent.

Action item review

Keith has begun meeting with Mike to understand Gluu better re its software tests.

Eve has learned that Gluu has pushed forward on extensibility of policy profiling.

Sketch elements needed for an "UMA-protected OpenID Connect", including discovery of claim types available through an AS

What would UMA-protected OpenID Connect look like? The goal would be to expand the possibilities for authorized sharing of identity claims (a subspecies of protected resource), so that you could have Alice-to-whoever sharing. E.g., Alice might want to share with Bob her health status after a particular medical test is done, without giving him her password etc. and without her having to be awake and logged in somewhere at the moment he tries to access the resource. UMA enables sharing with RPs (relying parties) who aren't necessarily SPs (service providers) to the resource owner.

In the past, we've discussed this in the context of "true access-controlled sharing" – the requesting party doesn't have to be a user of the resource server, with an account there, to get access; they just have to qualify in according to the resource owner's policy. E.g., Alice could meaningfully restrict Flickr photo access to Bob even if he doesn't have a Flickr login. But this UMA-protected OIC use case is a bit different; it's the reciprocal. What we want to do is stand up UMA protection in front of the AP (attribute provider).

For the Street Identity scenario, if we assume Google as the OP and Verizon as the putative AP, can we say that Google would be the UMA AS and Verizon would be the UMA RS? Normally the AP in OIC would be responsible for managing the release of claims, though OIC hasn't ?? really standardized AP-related flows. Would the AS now centrally take over? OIC says nothing about how you ask for or get authorized to have distributed or aggregated claims. The assumption has been that the RP gets the user to authorize access to some set of claims for which the user is the owner.

Nat notes: OIC is completely silent about RS/AS interactions and account linking. The RP gets the access token and requests access from the RS in the usual way.

Let's use Bob as patient and Carl as family member. There's a "distributed claim" about Bob that gives a trusted value for his HIV status. Bob wants Carl to be able to look this up. Bob sets up a policy that "pre-authorizes" Carl at Bob's AS/OP. The OP/AS application software might make it easy for Carl to learn the location by generating an email to him with the link to the resource. Carl would ultimately have to cough up an OIC ID token with whatever claims asked for in order to "qualify in" for getting all the way to the claim resource.

Is this special sauce, or normal UMA, or normal OIC? Can you take an ID token from an OP and send it to some random resource and have something happen? If the OP/AS generates an email with a special link, the link could effectively inform Carl (and his OP) what claims are going to be requested so that Carl can show up with the necessary ID token that is presumed to satisfy all the needed claims? In vanilla UMA, Carl would show up as "anonymous" at first, then while at Bob's OP/AS (which now functions as an OIC client), gets redirected to his OP to unroll the process of providing claims. Eager supply of claims/ID token would be new.

So if we can solve doing discovery of resource types (including identity claims), then that would get us pretty far. The UMA AS app developers can do a lot to facilitate "personal discovery" of a person's preferred photo service, etc.

Attendees

As of 27 Nov 2012, quorum is 6 of 10.

1. Eve
2. Alam
3. Domenico
4. Maciej
5. Keith
6. George
7. Sal

Non-voting participants:

• Nat

Next Meetings

• Focus meeting on Thursday, Mar 7, at 9am PT (time chart)
• Focus meeting on Thursday, Mar 14, at 9am PT (time chart)
• Focus meeting on Thursday, Mar 21, at 9am PT (time chart)
• All-hands meeting on Thursday, Mar 21, at 9am PT (time chart)