UMA telecon 2011-04-14

Date and Time

• WG telecon on Thursday, 14 Apr 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-03-10 and 2011-03-31 meetings
• Action item review
• Leadership team elections
• Dynamic client registration I-D status/plans
• Scoped access status/plans
  • Update from ad hoc meeting of previous day
• AOB

Attendees

As of 24 Feb 2011 (post-mtg), quorum is 7 of 13.

1. Adams, J. Trent
2. Mohammad, Alam
3. Bryan, Paul
4. D'Agostino, Salvatore
5. Hardjono, Thomas
6. Machulak, Maciej
7. Maler, Eve
8. Moren, Lukasz
9. Wolniak, Maciej

Non-voting participants:

• Kirk Brown
• Mark Lizar
• Frank Wray

Regrets:

• Domenico Catalano
• Susan Morrow
• Cordny Nederkoorn

Minutes

New AI summary

Roll call

Quorum was reached.

Approve minutes of 2011-03-10 and 2011-03-31 meetings

Minutes of 2011-03-31 meeting APPROVED.

• Action item review

• 2010-11-18-4 Eve Open Capture new user stories in the wiki.
• 2011-01-27-1 Paul Open Revise the Claims 2.0 spec to reference and profile JWT.
• 2011-02-10-1 Alam Now closed Share details of his planned UMA demo with the list.
• 2011-03-02-1 Nat Open Put together JWT-compliant examples of Claims 2.0 and Simple Access Authorization Claims.
• 2011-04-07-1 Eve Now closed Figure out how to do a keep-alive revision of the dynamic client reg spec.
• 2011-04-07-2 Frank Open Match constellations to scoped access diagrams to see what happens. In progress.
• 2011-04-07-3 Thomas Open Turn the results of the ad hoc call on scoped access into core spec text.

Fraunhofer SIT implementation status

Alam's team implementation efforts are focusing on resource registration, and they're working next on scope registration. At that point he'll send the project documentation to the group. The team has been discussing UMA concepts with a company that might be interested, but they're concerned about whether the AM could be a bad guy. Eve's brief thoughts on the topic: An AM is a "limited panopticon" (it can theoretically mint tokens to grant itself access to all connected hosts) whose actions have to be limited by a trust model. If a consumer IdP offers AM services, their reputation and trustworthiness come into play. Alam notes that Google's reputation in Germany is particularly bad. And trust frameworks may need to get more mature to handle this issue thoroughly. There are probably some technical/crypto/non-repudiation tricks that we can do to ensure that hosts can protect themselves from liability in the case of a rogue AM.

UMA FAQ

Let's build a FAQ and put together our best answers to tricky questions. IIW would be a great place to build this list. In attendance at IIW will be Trent, Eve, Maciej(s), Lukasz, possibly Sal, and possibly others.

Leadership team elections

Christian needs to step down as official spec editor ahead of his term expiring. The terms of some of the current WG leadership team are going to be expiring over the next month or two.

Thomas nominates himself for the role. Relatedly, he had offered review services on the OAuth use cases document, and has already turned in some comments. He's asked if he can submit additional UMA-related use cases, and they agreed. He notes that use case 3.12, which is healthcare-related, seems to be a dead ringer for UMA. The UMA hData scenario is also relevant here.

Dynamic client registration I-D status/plans

A keep-alive v01 draft is now available. However, we need to change the title, and should consider substantively revising the draft now that we're back out of draft expiration. Because we didn't include one of the author's last names, it looks like an orphaned individual submission. Also, it seems like a good idea to mention UMA in the title (for "marketing" purposes, so that people looking at the OAuth page know what the draft is about).

Should we drastically cut back the recommendations in this draft? For the provisioning of a requester access token, our needs seem to have been drastically reduced. (The same may or may not be true of provisioning the host access token.) Also, the OAuth community tends to use anonymous credentials for native apps, which means our long disquisition on that subject may not be necessary.

We'll spend real time on this next week.

Scoped access status/plans

The notes from the ad hoc meeting are in the archives and in the 'pad.

We did some more work on host-AM token validation in the 'pad, reproduced below:

Kirk asks: What about the "strength" of the token? What if the user wants to make policies about how strongly the requester can be correlated over time? Social networks require light weight and scalable processes for a broad consumer population. Alternatively, a healthcare provider scenario might require stronger authentication of the requester.

Can we lean on the OAuth token work in this regard? The bearer token draft assumes an opaque token, and there's work on a MAC token. Further, the JWT work allows for what we call the "meaningful token" option, where you can sign and encrypt significant token content. Today, OAuth has not participated in the ICAM Levels of Assurance work, though there has been interest in doing this; without more token work, they likely can't.

This kind of user policy has interesting interactions with the "attribute" styles of claims that we intend to be requested and delivered in a different part of the flow, namely the requester-AM authorization request.

We're agreed that the host doesn't care about the nature or strength of the token at all.

Paul objects to the requester having to separately "contract with" the AM in order to get an access token, since the AM is acting as Alice's agent. If Alice's policy dictates strong authentication of some requesting party, then this should happen at the claims stage, not the token stage. So he would prefer that we insist that token issuance be totally dynamic and, ulimately, meaningless with respect to user policy.

Frank's and Kirk's work on mapping use cases reflected an assumption that Alice had to manually provision some information to the requesting party. If Alice has many requesting parties in her life (which we hope she will), this process will need to be automated, and requesters really will need a dynamic way of getting the token to start the process.

In order to clarify the distinction between the token-getting stage and the authorization-getting stage, Paul would prefer that we ensure total dynamicism of token-getting! The requests for claims are at a later stage and a higher semantic layer.

Eve wonders if we can define, in the UMA spec itself, a baseline level of expectations (technical and business trust) associated with the sheer act of accepting a token from the AM. Paul would even push that to the claims stage, if the AM wants a positive statement of agreement.

Further discussion outside the 'pad:

We discussed the nature of the sharing of resource protection and scope information, noting that the AM has somewhat less responsibility than a classic PDP would because it's "dumb" with respect to the semantics of what's being protected, and doesn't give the host an authorization decision per se but rather a scope manifest that the host compares with the type of access requested.

Next Meetings

• WG telecon on Thursday, 21 Apr 2011, at 9-10:30am PT (time chart)
• WG telecon on Thursday, 28 Apr 2011, at 9-10:30am PT (time chart) (Eve may be a bit late - Maciej will initiate call and chair for first 15 min)