UMA telecon 2010-10-07

Date and Time

• WG telecon on Thursday, 7 Oct 2010, at 9-10:30am PT (time chart)
  • Skype line "C": +9900827042954214
  • US: +1-201-793-9022 | Room Code: 295-4214

Agenda

• Administrative
  • Roll call
  • Approve minutes of 2010-09-30 meeting
  • Meeting plans: summertime skew, F2F agendas and locations, subteam meetings
  • Action item review
  • KI funds disbursement plans
  • Updates from the wider UMA world
• Second review of proposed scenario dimensions
• Understanding trusted claims scenarios and proposed mechanism
  • See Domenico's trusted claims writeup and UX wireframes
• If time: revisit scope discussion and discuss Thomas's access control proposal
• AOB

Attendees

As of 30 Sept 2010 (pre-meeting), quorum is 6 of 11.

1. Adams, Trent
2. Catalano, Domenico
3. D'Agostino, Salvatore
4. Fletcher, George
5. Hardjono, Thomas
6. Hoffmann, Mario
7. Holodnik, Tom
8. Maler, Eve

Non-voting participants:

• Kevin Cox
• Herve Ganem
• Mark Lizar
• Jeff Stollman
• Aaron Titus
• Anna Ticktin (staff)

Regrets:

• Maciej Machulak
• Lukasz Moren

Minutes

New AI summary

Roll call

Quorum was reached.

Approve minutes of 2010-09-30 meeting

Minutes of 2010-09-30 meeting APPROVED.

KI funds disbursement plans

Trent notes that the budget prep committee is trying to do some balancing and assessing of 2010 needs vs. pushing things out to the future. What does the UMA WG want to do with the 2010 allocation of US$4K for a hostable validator bounty? There seem to be three choices:

1. Ask Kantara to put out the bounty offer now
2. Ask Kantara to put the money to some different purpose in 2010
3. Release the funds in 2010 and consider formulating any other 2011 budget requests at the Paris meeting

Trent believes that the WG itself has the sole authority to judge who could get the bounty (possibly splitting it among multiple parties). The only requirement is the "bounty" format. It would be valuable to set clear timelines for budget management reasons, such as announcing the bounty program with a response deadline of midnight at Oct 31, with a decision to be made by Nov 11 at the latest.

At the same time, we're not sure that the specs are quite ready/normative enough yet to have validation software written against them.

There are useful validation-related tasks that could be done right now, such as design documents and sample log output, but in the main they don't involve actual coding quite yet. Then again, the existence of UMA/j has spurred us to make faster spec progress than we might otherwise have, and it has a test suite. Eve feels that the Core and Claims 2.0 specs are squishy but usable, but the resource/scope registration piece is unfinished.

We should quickly get our location scenario in good enough shape to serve as a sample app development target. And we have a new urgency around choosing a resource/scope registration solution.

Is it kosher for us to award the bounty to someone who delivers an interim deliverable that contributes to an eventual validator? We believe so. Are we bothered by the possibility of "throwing a party and having no one come"? We are generally okay with it.

We'll plan to approve a bounty announcement by next Thursday, and try and get any KI input by then as necessary.

Updates from the wider UMA world

Eve notes that there is an active conversation taking place on the "Personal Data Store/Service" topic; the Planet Identity blog aggregator and the ProjectVRM mailing list are two places where this is taking place, and it's likely to be heavily discussed at IIW XI.

We discussed the notion of DRM and its relationship to UMA. Eve's position paper had made the case for not solving DRM. George expresses a hope that DRM can be layered on top of UMA somehow, e.g. by signing or applying similar technical protections to the content being shared, but agrees that we don't want to tie it into the core authorization system that we're building. Herve observes that DRM has been "unfriendly" to date because it has imposed uncomfortable constraints on using the data.

Jeff S. passed along a request from the P3WG for a short UMA presentation at their meeting in two weeks. Eve asked him to send the particulars to our list, so she can find a willing speaker.

Understanding trusted claims scenarios and proposed mechanism

• See Domenico's trusted claims writeup and UX wireframes

We discussed the notion of a claims catalog now presented in Domenico's materials. Can we leverage the JSON Web Token concept to simplify the flows shown on page 3? If Bob is trying to access the photo through a Google app in the first case, it should be possible to shorten this cycle; essentially, there are efficiencies if the chosen requester app happens also to be (or proxy for) the necessary claims host. But in general, we don't want to compromise Bob's privacy.

To the extent that the requester app has to talk to another service, have we invented something that isn't successfully chain-able? Can you marry an identity token with a "right to present" it, such that Bob (or a smart client on his behalf) could give it to the requester to present at will? Once the claims are presented the first time, the requester gets an access token they can use (without knowing the claims at all), and if they get a refresh token too, they can keep getting fresh access tokens without having to make Bob go and log in again. But the access token is something like a "quintuple" of AM1, the requester app, Bob, AM2, and IdP2.

It helps Bob significantly if he can let the authorizing users in his life know which IdP he prefers to use, so that their ACLs name "bob@gmail.com" instead of "robert@hotmail.com" or whatever.

Does the notion of trust frameworks help us? It helps AM1 and AM2 communicate without much fuss. But does it help with anything else?

Another simplifying pattern is when AM2 is colocated with IdP2.

However, note that even if both Alice and Bob use CopMonkey as their AM, we still have to maintain a wall of separation between their activities, seeing it as "AM1" and "AM2" regardless.

(Don't forget that AM2 might support identity federation, such that the way people log in to it is to use AOL.com!)

Is it legitimate for us to think of a bob@gmail token as a "SSO token", such that there is value in using a current session (or forcing Bob to log in to create a fresh session) in order to trust a short-lived token saying who he is? We've been assuming that trust frameworks and LOAs will be in use here. What impact does it have to inject an AM into the picture, which usually only has IdPs, RPs, and users?

Where should the trusted claims problem be in our priority list? Sal opines that maybe it's an "IdP problem", and maybe AMs should have a list of "trusted IdPs". But George feels we need to solve for conveying the claim in the UMA part of the system.

Next Meetings

• WG telecon on Thursday, 14 Oct 2010, at 9-10:30am PT (time chart) on line C
• WG F2F on Wednesday, 20 Oct 2010, at 9am-noon CET (time chart) - no dial-in, and no telecon this week
• WG telecon on Thursday, 28 Oct 2010, at 9-10:30am PT (time chart) on line C
• WG F2F on Monday, 1 Nov 2010, at 11am-5pm PT (time chart) - no dial-in, and no telecon this week
• WG telecon on Thursday, 11 Nov 2010, at 9-10:30am PT (time chart) - Maciej to chair?