UMA telecon 2010-03-10

Date and Time

• Day: Wednesday, 10 Mar 2010
• Time: 9:00am-12:00pm PST | 12:00-3:00pm EST | 17:00-20:00 UTC (time chart)
• On-Site:
  • Intel offices in Hillsboro, JF3 building, room JFCC121 (conference details)
• Dial-In:
  • Skype: +9900827042954214
  • US: +1-201-793-9022 | Room Code: 295-4214 (other local country numbers available on request)

Agenda

• Roll call
  • Reminder: no call this Thursday
• Approve minutes of UMA telecon 2010-02-18, UMA telecon 2010-02-25, and UMA telecon 2010-03-04
• Action item review
• Discuss upcoming events
  • Action items for IETF77 OAuth meeting on March 22
  • Public meeting at EIC on May 3
  • IIW (May 17-19) and Web 2.0 Security and Privacy workshop (May 20) plans
• Detailed spec proposal review and disposition
  • Review protocol issues list
  • Next steps for uma-dev list
• Scenario dispositions
  • Custodian scenario
  • Protected inbox scenario
• Requirements dispositions
• AOB

Attendees

As of 10 Mar 2010 (pre-meeting), quorum is 8 of 15.

1. Adams, Trent
2. Andrieu, Joe
3. Andres, Charles
4. Catalano, Domenico
5. Fletcher, George
6. Holodnik, Tom
7. Kellomaki, Sampo
8. Machulak, Maciej
9. Maler, Eve

Non-voting participants:

• Ingo Friese
• Gael Gourmelen

Guests:

• Joni Brennan (staff)
• (Several silent observers)

Regrets:

• Paul Bryan
• Hasan ibne Akram

Minutes

Roll call

Quorum was reached. Charles Andres introduced himself; he started the Information Card Foundation, but is now involved with a personal datastore startup.

New action item summary

Approve minutes of UMA telecon 2010-02-18, UMA telecon 2010-02-25, and UMA telecon 2010-03-04

Motion to accept these minutes APPROVED.

Action item review

• 2009-12-03-04 Eve Open Add terms-negotiation scenarios to Scenarios document. It's time to reactivate this one.
• 2010-01-28-2 Joe Open Edit protected inbox scenario in response to telecon and email discussion: Now closed.
• 2010-02-25-2 Maciej Open Revise the custodian scenario according to today's discussion and email feedback: Now closed.

Action items for IETF77 OAuth meeting on March 22

We need to discuss today:

• Use cases for message signatures? token signatures?
• Use cases for back-channel token validation
• Terminology on the IETF OAuth wiki

Only Eve is attending IETF77. Let's assign these as action items during the course of the meeting.

Public meeting at EIC on May 3

This will be held on the Monday morning. It's free to attend, but you may have to register with the EIC folks ahead of time.

IIW (May 17-19) and Web 2.0 Security and Privacy workshop (May 20) plans

Eve and Maciej are both planning to attend IIW and the workshop. George, Trent, and Joe likely to attend IIW.

Detailed spec proposal review and disposition

We walked through the new spec proposal, using the first set of Domenico's V4 diagrams as a guide and discussing issues and questions along the way.

History and future: Originally, ProtectServe was built on a mix of OAuth 1.0 and something that just approximated it. UMA's first spec draft was built on OAuth 1.0 for real (and XRD and LRDD). We're now considering UMA on WRAP (and hostmeta and XRD) with some profiling and extensions, on the way towards UMA on OAuth 2.0 with well-identified profiling and extensions where necessary. We very much want to encourage the OAuth 2.0 work to become stable quickly, given the new dependency we have taken on.

Multiple AMs per resource: It's Paul's belief that leveraging the WRAP paradigm means we don't have an obvious way to put multiple AM protections in front of a resource. It's our assumption that the proposed path makes possible only a single UMA AM per resource; that it's always possible to switch the AM-of-record protecting a resource with UX (but not protocol) implications; and that any non-user-managed access control (say, mandatory access control (MAC) imposed by an employer) is applied in a way that is entirely invisible to UMA.

Need for refresh tokens: Is there something about UMA that suggests we always need a profile that offers refresh tokens? Would, e.g., a SAML token profile be okay? We're not currently sure, but this may impact the place in the flow where claims provisioning comes in.

Signing: Using today's WRAP, an UMA authorizing user can't be absolutely sure (based on a signed message) who accessed his protected resource, other than the client's IP address. It's only indirectly known by the AM, and that's only if a user policy made the AM demand some claim from the requester, and even so the authentication is at a "higher" level of the stack. So wherever there's a use case that requires that the access token be bound to the requester who wields it, we need signatures.

This nets out to the requesting party (person or company seeking access) having an incentive to say "It's really me accessing this", such that it mitigates the risk that the requester (client) will hand off both the access token and the signing secret to a third party. Online banking might rise to this level. But if you install TurboTax on your PC, is it likelier that you the requesting user would sign something that gets bound to your TurboTax instance, or sign something that gets handed to your TurboTax instance as a bearer token that they use on your behalf without the binding? TomH feels that, yes, it's quite possible for this to be a value-add provided by something like TurboTax as a "trusted computing" offering.

It was observed that the argument in the OAuth community about token size seems to be related to token signing, thusly: those who are willing to require the Authorization Server to be stateless need large meaningful tokens and want them signed; those who can use a stateful Authorization Server can use small opaque tokens that don't need signing.

Back channel for token validation: Our "token validation URL" proposal is just a strawman. There are quite a few motivations for wanting this back channel, though:

• It allows for building a very lightweight host that can do token validation at request-time.
• The AM is the best entity to judge the token's suitability.
• Once this channel is enabled, the host can use it send audit log data to the AM for more interesting analytics.
• Or the AM could (at leisure after step 1 is done) dynamically provision the host with the ability to do local token validation (which ends up looking like a hybrid remote/local means of validation).

IETF OAuth wiki terminology: We would recommend that WRAP/OAuth adopt Host – or, likelier, some other different term so that we can continue to use Host for something that embodies multiple WRAP endpoints – for what is currently called the Protected Resource. This is because even if the current WRAP use cases don't allow for scoping other than one token per web resource at a PR, ours do (e.g. "all the photos in this set") and it's hard to talk about this use case with "PR" in the mix. Also, it's just plain confusing: WRAP I-D Section 4.5 says: "The Protected Resource MAY allow the Client to access protected resources at the Protected Resource by..." !

UMA terminology: Our own terminology is a bit confusing because "Claim" is defined only with respect to claims conveyed on behalf of the Requesting Party, while infocard-type claims would normally be about the Authorizing User. We need to clarify this.

Getting WRAP/OAuth 2.0 concerns on the table: We identified the following concerns:

• WRAP is currently written in an extremely flexible and unspecified way, which can seriously impact interoperability. We will have to carefully consider these flexibility points and "select options and close gaps" in an UMA profile, along with any extensions we have to define.
• We need to ensure that we can cover both person-to-person sharing and person-to-service sharing use cases, and even use cases that involve migration from one to the other. We think we can do this using either existing WRAP-style token-getting profiles or defining new ones, but we have to monitor this closely.

Decision: Motion to Accept WRAP as a substrate for the UMA 1.0 core protocol work, on the way towards OAuth 2.0 usage, was APPROVED.

Protected inbox scenario

Eve asks Joe to offer more specifics in his scenario. He will add Sally/InfoSharing details, and also more details from the what/how/when/who regulations that Iain described. He will also update to reflect our WRAP-oriented discussions.

Custodian scenario

Maciej has now added our new terminology for "primary resource user" (see the Lexicon) to his scenario. He has also incorporated an analysis of how UMA can be used for "mandatory access control" (MAC). We will try to decide the disposition in next week's call.

Next Meeting: UMA telecon 2010-03-18

N.B.: U.S. Daylight Savings Time is in force for this meeting, and UTC correspondingly "shifts".

• Day: Thursday, 18 Mar 2010
• Time: 9:00am-10:30am PST | 12:00-1:30pm EST | 16:00-17:30 UTC (time chart)
• Dial-In:
  • Skype: +9900827042954214
  • US: +1-201-793-9022 | Room Code: 295-4214 (other local country numbers available on request)