UMA telecon 2010-01-14
Date and Time
AttendeesAs of 12 Jan 2010, quorum is 9 of 17.
Guest:
Regrets:
Agenda
MinutesRoll callQuorum was reached. Approve minutes of UMA telecon 2009-12-17, UMA telecon 2010-01-07Motion to accept minutes APPROVED. Action item review
Webinar planningTitle: "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. Lexicon discussionEve 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. Consider UMA logo ideaThe 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. Opportunity to provide scenarios as input to the OAuth processThe 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. Review scenario docketEve's goal is to get all the awaiting-submission scenarios submitted by next Thursday.
CustodianShould 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:
E-commerceThis 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. Walk through personal loan wireframesDeferred. Please do this on your own time and send any thoughts to the list. New action itemsNew AIs:
Next Meeting: UMA telecon 2010-01-21
|
Bookmarks
Is this site useful to you? Please share it! On This Page:
Pages in this Space:
|