As of 12 Jan 2010, quorum is 9 of 17.
Guest:
Regrets:
Quorum was reached.
Motion to accept minutes APPROVED.
Title: "UMA Update: Making the world safe for user-managed access"
Proposed abstract: "When dealing with many websites, the price we're forced to pay is to "hand over the data" – data that's sensitive, valuable, and personal. The new User-Managed Access web protocol promises to help web users share their data more selectively to better effect, and to help websites get access to fresher and better-quality data. This session will review UMA benefits, progress to date, and next steps."
Joe suggests adding something that will help the abstract distinguish UMA from OAuth.
In addition to slides, which Eve will draft this weekend for webinar team review, Paul will prepare the "peekaboo" version of the swimlane diagrams. We think Domenico's recent graphics will be used heavily in the slides. We'll have the ability to take phone and WedEx "raise your hand" question to help us know what to deep-dive into.
We'll have a limit of 25 people who can attend; we'll limit our own attendance to 5.
Eve proposed some definitions (sans terms) in email:
Joe suggests that #3's definition needs a change: Who deployed the application isn't quite right given that there might be a "requester delegate" in play (an outsourced cloud-based host). We want to express that #3 is somehow on the hook (liable) for the access that ultimately gets granted; it's on their behalf that the #2 application is deployed, even if they didn't deploy it themselves. Paul gives the example of his Google calendar is trying to access Joe's Google calendar. Google is the #3.
Tom makes a connection to the Custodian scenario (to be discussed shortly). Eve cautions that some seemingly custodian-related use cases might, in reality, turn out to be vanilla UMA use cases, without a need to split the "authorizing user" into multiple concepts the way we're splitting "requester" into five concepts here.
The intent behind the option of "natural person" in the definition of #3 is that some people might really run their own mail servers, blogs, and UMA requesters. These people could be said to be in the #5 role as well, in this case, and even in the #4 role.
Is the agreement forged between the authorizing user and #3, or between the authorizing user and #5 (if present)? Or is it a combination of both, depending? For example, Paul might want to make Google not cache the data for too long – but might also want Joe not to expose Paul's calendar availability to other people. If you're allowing the soccer team to see photos, you are granting that access to the soccer team and not to others they might want to pass the photos along to. People in the #5 role aren't in a very good position to "speak for" #3 companies (like Kinko's for printing the photos) in promising anything. This is where standard agreements, and safe harbor statements that say a party isn't liable for certain things others do, can perhaps come in.
Tom asks about #4. Joe explains it as the "Foto-Mat pornography problem"! Eve had thought that a person who works for #3 and represents them may, in the course of events, be involved in the access-granting process (clicking "I Agree" or solving a captcha on an UMA-mediated screen), which has UX and legal implications, if not protocol ones. But a different #4 person may be involved in actual data/service access, which is indeed the Foto-Mat porn problem and has legal implications at the least.
The group generally likes the logo itself and the idea of visually representing UMA in various materials.
Motion to make Domenico the UMA Graphics/UX Editor APPROVED. (Whoo-hoo!)
Domenico has agreed to contribute the logo to Kantara for management.
The OAuth telecons are scheduled. The current plan is for us to submit information about our approved UMA scenarios in email to convey our key use cases (endpoints, parties, actions, etc.). Does this have to be in I-D form to be effective? It might not be quite as effective if just in a plain email, but there may be IPR questions around the I-D approach. Let's do the email approach for now, and see how it goes.
Eve's goal is to get all the awaiting-submission scenarios submitted by next Thursday.
Should we add an ACL aspect to this scenario? Yes. George notes that AOL does a lot of both ACLs and parental control already. ACL management is a nightmare today because it can't be shared or factored out from multiple control points.
Eve is a bit worried that we're combining together two things in this scenario:
Don't miss George's and Praveen's blog entries about identity tokens on this subject:
This is getting closer. Hopefully the people who have commented on it in the past, at least, can review it closely and decide if it has a clean bill of health.
Deferred. Please do this on your own time and send any thoughts to the list.
New AIs:
Eve |
Open |
Revise webinar abstract with the webinar team's help and get it onto the relevant websites. |
|
|
Eve |
Open |
Revise requester definitions for review. |
|
|
Domenico |
Open |
Develop wireframes for approved scenarios. |
|
|
Domenico |
Open |
Contribute UMA logo to Brett for future Kantara management. |
|
|
Eve, Paul, George |
Open |
Construct a draft use-case email for OAuth IETF group consumption. |
|
|
Maciej |
Open |
Revise custodian scenario |
|
|
Mike M. |
Open |
Check on whether he should be writing an information card use case. |
|