UMA telecon 2010-02-11

Date and Time

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

Attendees

As of 11 Feb 2010, quorum is 9 of 17.

Akram, Hasan
Andrieu, Joe
Bryan, Paul
Fletcher, George
Hanson, Michael
Machulak, Maciej
McIntosh, Michael
Maler, Eve

Non-voting participants:

Richard Levenberg

Regrets:

Domenico Catalano
Trent Adams

Agenda

Roll call
Approve minutes of UMA telecon 2010-02-04
Action item review
Review F2F agenda objectives
Review mobile consent wireframes
- What UX to prioritize next?
- Scenario disposition, protocol issue disposition, maybe requirements disposition
Requester and authorizer lexicon discussion
Scenario review
- Custodian (splitting authz-side parties)
- Employer/employee (other mandatory access control)
  - And the "multiple protections on a resource" thread
- Health data (trusted dynamic resource discovery)
AOB

Minutes

New AI summary

2010-02-11-1	Paul	Open	Develop new core spec draft.	Hopefully by next call.
2010-02-11-2	Dom	Open	Develop wireframes that explore data-sharing analytics possibilities.	Eve to ask Dom to take this on.
2010-02-11-3	Eve	Open	Edit terminology section in core spec.
2010-02-11-4	Maciej	Open	Recommend terminology around custodianship on the mailing list.

Approve minutes of UMA telecon 2010-02-04

Deferred due to lack of quorum.

Everything's still pending, except that Iain provided slides to Eve and asked that any distribution be on the condition that individual recipients promise to keep them in confidence. All the people on the call agreed.

Review F2F agenda objectives

Scenario disposition, protocol issue disposition, maybe requirements disposition

We will have a phone line available. We have a very ambitious agenda.

Spec review

Paul reports: He and George did an intensive walkthrough of the spec offline. George's main concern was that we had proper linkages of specific identities all the way through. He notes that the requester application takes on a responsibility for managing various relationships well (an implementation concern), but agrees with Paul that the lines do go straight through. There will be some impacts on how the formal spec text clarifies some points.

Paul and Eve report: They met with Eran Hammer-Lahav to review our usage of OAuth, XRD, and LRDD. Eran felt we're currently overusing discovery for flexibility purposes, at the great expense of simplicity. He recommended using hostmeta and well-known locations along with a simplifying assumption about the form in which the user provisions a host with the location of the user's chosen AM. A template in the host metadata can indicate how to discover metadata for specific resources at that host. Eran also shared the latest news and progress on the discovery and metadata spec work in which he's involved.

As a result, the current thinking is that Step 1 will be greatly simplified and shortened, which sounds great to all concerned. We need to be able to motivate every back-and-forth in the protocol pretty strongly. George adds that we should call out relationship mappings in each interaction.

Paul asks: The "referral" mechanism is still pretty heavy; can we consider getting it out of the picture? We could instead impose two-legged OAuth between the requester and host as the authentication mechanism, which would simplify things a lot. We could still consider ourselves to have "gotten out of the business of OAuth" (vs. what we did in the ProtectServe days), but we're backing a particular authentication horse. George comments that AOL has discovered, in doing this for their OAuth support, that some deployers complain because they're distributed across the world and it's expensive to go back to the token issuer in every request. Mike H. notes that OAuth is a moving target, so this gives some pause, but "we have to believe in something" so maybe it's okay.

We're generally agreed that we'd really like to manage correlation of all the identifiers in a way that doesn't involve the complexity of "referral" resources, so at least we want OAuth or its moral equivalent. Authentication and access tokens still have happen per user/requester/host tuple. Joe asks: Which user are we talking about here? Good question! We mean "requesting party"/requester/host.

Paul will experiment with both of these changes in the spec.

Review mobile consent wireframes

No comments on the mobile wireframes – looks great!

Mike H. suggests that the next area worth exploring is analytics and audit logs. Policy and consent are relatively simple, while analytics present lots of opportunity for value-add. Joe calls this the "morning-after" scenario. (Goes nicely with the "hey, sailor" scenario. rimshot)

Requester and authorizer lexicon discussion

Joe suggests creating a lexicon aside from the protocol spec.

Eve's definition exercise back on Feb 4 led her to conclude that (a) it's especially hard to define similar terms in the case of the host, and (b) it would be ideal not to have the party/intermediary terms (the legalese) defined in the protocol. Joe suspects we'll need to keep the legal definitions in the spec because claims are only about legal parties. Paul agrees that it's likely claims will be about the requesting party, but it's not guaranteed to be the case. For example, a claim could be required that just makes the requester do enough work to ensure they're not perpetrating a DoS attack on the AM.

Eve wonders if anything "legal" about claims can be said to be a testable assertion, in the sense of testing software's compliance to the spec. Maybe we can discover the answers to these questions by writing both the protocol spec text about "chains of identities" and an "agreements white paper" that incorporates the legal definitions.

Regarding sets of endpoint vs. application vs. service terms: Joe has defined "service" versions of the terms for InfoSharing purposes, but Eve hasn't done it for UMA purposes. We seem to need the endpoint terms for sheer protocol definition purposes, and the application terms for "speaking to developers" of the protocol in the protocol spec (e.g. discussing work that's out of scope, or offering occasional non-normative best practices advice). We don't seem to need the service terms today, since they reflect deployment concerns, but maybe we'll discover a need for this later (either in the spec itself or in other collateral).

George suggested grouping the terms would be useful; there's nothing magic about alphabetizing them.

Joe would like us to follow Tom's advice in not having legal vs. other terms. We think we can combine authorizing user/party (with "user" winning). People generally agree. Does it work for requester side? In that case, Joe suggests we use "requesting party", and pushes back on a definition that says the requesting user has to be a "web user" – what if they walk up to the Kinko's counter to print a calendar that uses photos gotten from elsewhere. Eve argues that, to date, we have always assumed that any requesting user is interacting online; we haven't accepted this scenario yet.

Joe suggests "authorizing intermediary" should be "authorization intermediary". Eve agrees.

Next Meeting: UMA telecon 2010-02-18

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