[Wg-uma] Draft minutes of UMA telecon 2009-10-08

[Eve Maler]

NOTE: Please keep an eye out for email explaining what our call time  
will be.  It will be either 9-10:30am Pacific OR 1-2:30pm Pacific.   
Thank you!

The draft minutes are here; please let me know if you see any  
inaccuracies:

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2009-10-08

The action item and resolution summary is here:

http://kantarainitiative.org/confluence/display/uma/Meetings+and+Minutes

The minutes are also pasted below, for your convenience.

	Eve

Date and Time
Day: Thursday, 8 Oct 2009
Time: 9:00-10:30am PDT | 12:00-1:30pm EDT | 16:00-17:30 UTC (time chart)
Dial-In:
Skype: ++9900827042954214
US: +1-201-793-9022 | Room Code: 2954214 (other local country numbers  
available on request)
Attendees
Voting participants:

Akram, Hasan
Bryan, Paul
Catalano, Domenico
Davis, Peter
Hanson, Michael
Lizar, Mark
Machulak, Maciej
Maler, Eve
Scholz, Christian
Smith, Bill
Stollman, Jeff
Guests:

Joni Brennan (staff)
Regrets
Trent Adams
Iain Henderson
Agenda
Roll call
Approve minutes of UMA telecon 2009-10-01
Discuss upcoming meetings:
Add variation to group meeting time to make it easier for Japan-based  
participants?
IIW planning
Action item review
Michael: Create a scenario, or a use case off the Calendar scenario,  
that explores the need for entity #4 to approach the other entities in  
the context of some unique entity #5.
Eve: Confirm IIW-timeframe meeting location.
Revise the wording of the "Resource-specific policy limitations"  
requirement.
Discuss spec progress (Paul)
Review proposed requirements
Discuss new and revised scenarios and schedule acceptance votes
AOB
Minutes
Roll call
Quorum not reached.

AI:

Eve	Open	Do a non-voting participant declaration round. Make this a  
standing action item whenever a meeting has not reached quorum.)	
Approve minutes of UMA telecon 2009-10-01
Deferred due to lack of quorum.

Discuss upcoming meetings
Add variation to group meeting time to make it easier for Japan-based  
participants?
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.

AI:

Eve	Open	Check with Nat to see if we can start an every-fourth-week  
meeting time change on Oct 15.	
IIW planning
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.

Action item review
Michael: Create a scenario, or a use case off the Calendar scenario,  
that explores the need for entity #4 to approach the other entities in  
the context of some unique entity #5. This is CLOSED, based on his  
email that Eve forwarded to the list this morning.
Eve: Confirm IIW-timeframe meeting location. CLOSED.
Paul: Revise the wording of the "Resource-specific policy limitations"  
requirement. Still OPEN.
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
We discussed Mike's new scenario, forwarded to the list with comment.

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.

AI:

Eve	Open	Shove Mike's scenario/use case into the Scenarios document.	
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.

AI:

Eve	Open	Capture the two emerging design principles we have identified  
to date in the Requirement document.	
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.

Distributed services scenario
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.)

AI:

Eve	Open	Invite Project hData's Gerry Beuchelt to next week's meeting.	
Next Meeting: UMA telecon 2009-10-15
In next week's call, we'll focus on:

Review spec text
Distribute services scenario and its several use cases
Day: Thursday, 15 Oct 2009
Time: TIME MAY CHANGE: STAY TUNED:9:00-10:30am PDT | 12:00-1:30pm EDT  
| 16:00-17:30 UTC (time chart) ????
Dial-In:
Skype: ++9900827042954214
US: +1-201-793-9022 | Room Code: 2954214 (other local country numbers  
available on request)


Eve Maler
eve at xmlgrrl.com
http://www.xmlgrrl.com/blog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20091008/660da614/attachment-0001.html