UMA telecon 2010-06-24

Date and Time

• Thursday, 24 Jun 2010 at 9:00am-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-06-17 meeting
  • Action item review
  • xml2rfc/I-D/github/bitbucket status and issues
• Focus meeting report and discussion
  • Hold another focus meeting on 30 Jun 2010?
  • How are we doing on our "rough-out Step 1 by end of June" goal?
• Dynamic client registration
• RRAPI
• Third-party-asserted claims, "identity tokens", trust model
• AOB

Attendees

As of 3 Jun 2010 (post-meeting), quorum is 6 of 10.

1. Catalano, Domenico
2. Gamby, Randall
3. Hardjono, Thomas
4. Maler, Eve
5. Moren, Lukasz

Non-voting participants:

• Aaron Titus

Guests:

• Anna Ticktin (staff)

Regrets:

• Maciej Machulak
• Joe Andrieu
• Christian Scholz
• Tom Holodnik

Minutes

Roll call

Aaron was invited by Mark Lizar to join. He is an attorney in D.C. He is the privacy director for the Liberty Coalition. He is running a National ID Watch project. And he's also spending effort on Privacy Commons, which has a user-centric rather than a data- or corporate-centric.

Quorum was not reached.

Approve minutes of 2010-06-17 meeting

Deferred due to lack of quorum.

Action item review

• 2009-12-03-4 Eve Open Add terms-negotiation scenarios to Scenarios document.
• 2010-05-27-3 Eve Pending Find and distribute info on the new proposal for OAuth signing. It seems to have been broken out from the core OAuth spec.
• 2010-05-27-4 Eve Pending Ask Dave Crocker for help with Step 1 user stories. No progress.
• 2010-06-17-1 Christian, Eve Open Work on the conversion of the core spec and the dynamic registration spec to xml2rfc. In process.

Focus meeting report and discussion

• Hold another focus meeting on 30 Jun 2010?

Not sure yet. Eve will coordinate with the absent folks and let everyone know.

• How are we doing on our "rough-out Step 1 by end of June" goal?

We think we're doing pretty well.

In the SMART implementation, the AM publishes XRD material that the host retrieves in order to get fully introduced to the AM by the authorizing user. This is pretty much the way our current spec says to do it.

Nat has proposed that the dynamic registration of the host with the AM (outside of the context of any user) use the AB model ("pull") and techniques (possibility of signed metadata etc.). He will try to harmonize all the proposals and present us with new thoughts soon. At the same time, Eran H-L is working on the somewhat similar "OAuth Discovery", which we know we will have opinions about. Our plan of record is to submit an I-D specifically about this, to influence that work. We believe Eran is planning to work on OAuth Discovery right about now, so time is of the essence.

Our Step 1 involves an overarching goal of having the user get the host and AM to trust each other for (respectively) authorization and hosting services in the context of the user. Should we stick to the word "introduction" for this process? Yes; using the word "registration" seems to be too confusing. We should reserve "registration" (if that's even appropriate? that registration involves discovery but that's not the whole story) for processes having to do with a host dynamically signing up for credentials at an AM. This has an impact on the spec-writing we do (Christian and others, please note!).

In fact, we think the general problem to be solved is "automated self-registration of a a client account with unique login credentials at an authorization server"! So maybe that can be the definition of some shorter name.

RRAPI (resource registration API)

Nat has proposed that the host statically store its resource details on its own site and have the AM "pull" it, vs. our current proposal (which is to "push" the information in an OAuth-protected manner). Eve and Randall suspect that pushing is better, since there will be less latency and network traffic that way: the host could push the info whenever the user updates info on the host, vs. the AM polling/pulling periodically even if nothing has changed. And the host access token authenticates the information just as much as the pull model seems to. We're willing to be convinced otherwise, but we'll assume a push model as our default approach for now. Maciej had floated an idea (not on the list yet) that the RRAPI could variously use either a push model or a pull model. Lukasz thinks he likes the pull model best at least for dynamic registration, and maybe also resource registration. We have some more thinking and testing to do here.

Third-party-asserted claims, "identity tokens", trust model

Eve reviewed the way in which our Step 2 enhances OAuth, namely, with the possibility of the AM asking the requester to pass along some claims. And she reviewed the three use cases we've been exploring:

• Alice-to-Dopplr (the most "OAuth-like" use case; Alice may want Dopplr to adhere to her own imposed policies)
• Alice-to-InfoUSA (InfoUSA is acting on its own behalf; Alice is in an even stronger policy position here)
• Alice-to-Bob (the nature of claims requested here would likely be different)

We acknowledge that there may be arbitrary numbers of intermediaries in between the end-to-end parties to an UMA-forged contract, and their pairwise terms of service may be looser than the UMA contract, thus "leaking" value. Our discussion at IIW taught us that the advent of modern trust frameworks may help here, if we can assure that all the UMA-compliant parties interacting together are members of the desired framework? Further reading for those interested in the legal subteam discussions:

• Legal Considerations doc (fledgling)
• Comments on doc from Jeff Stollman, and much further list discussion
• Notes from early discussion with Tom Smedinghoff (expand the "quoted text")
• IIW discussion led by Jeff S

The FTC has recently been concluding that the current regime of requiring "notice" isn't working very well. Aaron comments that his Privacy Commons work is trying to increase useful transparency of the consequences of sharing. We want to make sure to build the "offer and acceptance" pattern (that defines contracts vs. notice) into UMA. And, therefore, when the requesting party is a person, we want there to be some positive action on the part of the person – e.g., clicking "Yes, I agree to these terms" – which will generate the returned claim.

Regarding the Alice-to-Bob sharing scenario, there are particular technical complications having to do with technology, user experience, and sheer complexity of having lots of moving parts. Interestingly (to put it mildly!), Domenico has proposed a solution for identity claims that involves Bob having an UMA-protected claim (!!) that Alice's AM can pull (!!). For the same reasons that we tout UMA for allowing requesters to pull data directly from an authoritative source, pulling a claim about Bob from the authoritative source is also powerful.

Randall wants identities that are both strong and cheap. It seems a bit too early to force a solution here, but Eve hopes we're getting close to the "Identity Singularity" and need to pay close attention to see which emergent solutions solve our requirements.

Next Meetings

• ??? Possible focus group meeting on Wednesday, 30 Jun 2010, at 7-8am PT? (time chart)
• WG telecon on Thursday, 1 Jul 2010, at 9-10:30am PT (time chart)