...
- Day: Monday, 2 Nov 2009
- Time: 1:00-5:00pm PT (meeting held locally; no dial-in)
- Location: Boole room, Computer History Museum, Mountain View, CA (directions)
Attendees
Quorum is 12 of 22 (due to two signups during the meeting!).
Voting participants:
...
- Akram, Hasan
- Andrieu, Joe
- Bryan, Paul
- Curran, Sam (NEW)
- Davis, Peter
- Hanson, Michael
- Holodnik, Tom
- Machulak, Maciej
- Maler, Eve
- Smith, Bill
- Stollman, Jeff
- Windley, Phil (NEW)
Regrets
- George Fletcher (likely)
- Domenico Catalano
- Gregg Kellogg
Agenda
- Roll call and administrative stuff
- "IPR benediction"
- Shall we use #umaf2f along with #iiw as appropriate for tweets, pics, etc.?
- Approve minutes of UMA telecon 2009-10-29
- Action item review
- Spec review
- Latest: email
- Scenario development (docket)
- Focus on scenarios and use cases involving user-driven terms, policies, and demands for claims
- Understand where the IMI model of claim requests and responses may be able to help us
- AOB
Minutes
Roll call and administrative stuff
Quorum reached.
- "IPR benediction"
People attending and contributing to this meeting need to sign the GPA.
- Shall we use #umaf2f along with #iiw as appropriate for tweets, pics, etc.?
Yes.
- Approve minutes of UMA telecon 2009-10-29
Minutes APPROVED.
Action item review
Nothing has changed since Thursday.
Spec review
- Latest: email
We looked more closely at Step 3, which we know needs to change. Paul would like the host to get out of the business of deeply managing a requester's authorization, only being involved for correlation all the way through to the AM. Can the host create an "authorization resource" at the AM that the requester can then access?
If we do this, what is the right granularity/mapping for authorized resources to protected resources? The authorized resource could apply to a single protected resource for all its access methods, a single protected resource+access method (so, two authorized resources for calendar+GET and calendar+POST), all resources at that host for that requester, etc.
We want to avoid prematurely optimizing the answer here, and we want to ensure that we meet our simplicity goals particularly around the host endpoint, to increase adoption. Michael observes, looking at the OAuth session extension discussions, that we might want to keep the number of state tables on the host way down.
NEW emerging design principle: Complexity: Complexity should be moved to the AM endpoint vs. the host or requester, if possible. Comment: We anticipate dozens of AMs (maybe lots more if corporations have them), hundreds of thousands of hosts, and hundreds of millions of requesters.
In particular, Paul observes that ProtectServe had been turning into a kind of authentication protocol in order to achieve optimization, and we don't want to go there.
Do we need to profile OAuth specifically for use as our authentication substrate?
Note that there are two kinds of "two-legged OAuth": unique consumer keys, and unique access tokens. Google currently uses the former. (The access token has always been an optional parameter of OAuth.) But this pushes out-of-band the issuance of consumer keys and secrets. The other option is using an anonymous consumer key to negotiate a special access token. This is the moral equivalent of a person doing "self-registration" at a website. There's no identity assurance, just correlation going forward. The secret that backs the access token becomes a shared secret. So it's like automated self-registration, which is kind of cool.
Facebook currently has a per-application secret, and per-user privacy settings, but no way for a new application to approach Facebook Connect dynamically.
Where a requester is going to an AM for the first time, it needs to establish an identifier for use in future direct requests made to the AM.
Eve is a little worried that using "nonstandard" OAuth could be a barrier to developer adoption. But if we provision the consumer key right in the XRD, maybe the way it would be used ends up being pretty much like "regular" OAuth.
So Paul's current idea is that the requester asks the host for a "referral" over to the AM. This got us into a discussion of how he's proposed to use XRD to convey the challenge rather than in a 403 header. There is a variety of ways the XRD location can be indicated. Michael noted that on the webfinger list, there's been discussion on the propriety of subdomain XRDs, with Eran speaking against it. Since the same party might serve as a host for more than one user, to be truly "user-managed" it needs to have multiple XRDs.
If we had the freedom to invent another www-authenticate header, it would solve a lot. We're not sure yet if that's kosher.
If we have a whole bunch of XRDs, we're going to have to explain to potential hosts how they need to be prepared to serve up XRDs for their users if they want to take advantage of being a PEP.
In choosing between an XRD mechanism and a challenge-header mechanism, one consideration is that in the latter, you're declaring that info to be the "one true way" to achieve authorization. Experience shows that whatever method is last in a chain of such methods is the one that gets used, which is not necessarily the desired effect.
We went through a swimlane diagram exercise (click the link to see the resulting diagram).
The requester could forestall the beginning part of the process by getting the XRD some other way, before the 403 or even before the 401 (not shown) that preceded it.
Referrals are transient; their only purpose is to correlate a host's view of a requester's identifier with the AM's view of that same requester. Once the link is made, the referral stuff can go away. (The host and AM can happily manage that state separately afterwards.) The ID provided by the host can be the user ID, the session ID, or whatever is handy.
ISSUE for later: How and whether to request the "protected status" of a resource: To answer this question, a host would pretty much have to go through the same dance as for a request for actual access! It might be protected against requester A but not requester B, or protected with a real-time user consent loop, etc. We'll wait to see what real scenarios arise that need to be solved, and perhaps it will turn out that they can tolerate imprecision/latency. Before a host gives out the 401, it already knows intrinsically whether the resource is protected by some AM, and it has the ability to tell the requester this (whether this is a good idea or not we don't know yet). It just doesn't yet know whether the requester is going to be authorized to access it.
Since we're now out of the authentication business, keep in mind that whatever the host does in response to the initial approach of the requester is up to it. It can assign a pseudonymous form of identifier (possibly literally using a cookie-based method), or really anything. If the host needs to protect the privacy of the requester according to its own policies or applicable laws or whatever, it's up to the host to choose an ID wisely. We don't really care about protecting the requester's privacy, however; the whole point of letting the authorizing user control access is to let them do so on whatever criteria, and as part of that process the requester is simply going to have to authenticate, even if weakly.
NEW emerging design principle: Authentication: We want to stay out of the authentication business as much as we can. Comment: There are many technology choices here, and we want to be agnostic as to the right one for the job. Some scenarios may need stronger authentication and they should be free to use the right mechanism for the job. And setting up all pairwise relationships may be subject to some trust framework (e.g., some AMs might get blacklisted).
In the two-party introductions, we have the same vulnerability as OAuth around spoofed (not really phishing) sites. SSL/TLS mitigates this, as usual.
Scenario development (docket)
- Focus on scenarios and use cases involving user-driven terms, policies, and demands for claims
- Understand where the IMI model of claim requests and responses may be able to help us
TBS
Next Meeting: UMA telecon 2009-11-12
...