UMA telecon 2009-10-08
Date and Time
Quorum not reached.
Approve minutes of UMA telecon 2009-10-01
Deferred due to lack of quorum.
Discuss upcoming meetings
Eve had suggested to Nat Sakimura that we could schedule an occasional meeting time that's better for Asia participants, and he expressed interest. We think we could make every fourth meeting be at 1-2:30pm Pacific on Thursdays instead of 9-10:30am Pacific. It's clear on the Kantara calendar.
We have a meeting room confirmed in the Computer History Museum in Mountain View. We'll work up an agenda eventually. We might be able to "cleverly Skype" the event.
Discuss spec progress (Paul)
The spec writing has just begun. He has created some boilerplate content.
Review proposed requirements
Review the new Consumer Delegate scenario
Mike's goal was to avoid creating an "omnipotent token" that allows a requester app to use the token for access on the behalf of other parties. Mike based his scenario on concerns arising from recent OAuth discussions.
Eve suggests that a "base" scenario here is that there's a single human being as both the authorizing user and the requesting user, and that there's a single company that hosts its own Requester application. Mike's scenario is a variant where the company outsources its Requester application-hosting to another party (BizTools).
Do we think we can really solve this? Today, app-hosting relationships like this are common, and involve an sharing of private keys (covered by service-level agreements), and concomitant "impersonation" of the company by the outsourced service. We're inclined to say that distinguishing between the two parties is not in our scope. This would be our first "rejected" scenario/use case if so, which is a good thing for exploring exactly where our boundaries are.
Discussion of requirement P4
Christian made a comment on proposed requirement P4. Eve was trying out a requirement here, but seems to have gotten it wrong. Paul states the requirement as follows:
"Correlation of Authorizing User by multiple Hosts: For resources at Host X and resources at Host Y, X and Y must not find out, through their relationship with the AM, that the same Authorizing User uses the other Host." For example, a user might use the same AM to protect resources at LinkedIn along with their personal interests and hobbies.
We have tentatively agreed to this requirement, but we want to sleep on it (and don't have quorum to vote on it anyway).
A consequence of this requirement would be that the protection of the Authorizing User's privacy extends to trying to protect their connections to each Requester. However, because of the consistency of the IP address that might be used by the Requester app, we can't offer a blanket guarantee. Thus, we're inclined not to state this as a requirement.
New emerging design principle: Our goal is to protect the privacy of the Authorizing User as best we can, but when the AU is the same person as the Requesting User, they are not protected as a Requesting User.
Google's handling of desktop apps in OAuth
Mike notes that Google's recent OAuth deployment documentation suggests that they are somewhat outside the mainstream in their handling of desktop app flows – it redirects through a browser and through google.com. Security protection uses an "anonymous/anonymous" consumer key in their desktop case, which makes it weaker than the web app case. His recent email has more details.
Even though Christian had dropped off, we briefly discussed this. Let's put this on the docket for next week. Also please look at the Project hData scenario, which looks similar. (The main Project hData site is here.)
Next Meeting: UMA telecon 2009-10-15
In next week's call, we'll focus on:
Is this site useful to you? Please share it!
| | More
Pages in this Space: