N.B.: U.S. Daylight Savings Time is in force for this meeting, and UTC correspondingly "shifts".
As of 15 Mar 2010, quorum is 9 of 16.
Regrets:
Eve |
Open |
Edit the requirements document to add new DP 12. |
|
|
Eve |
Open |
Edit the lexicon to reflect the discussion of person-to-self sharing. |
|
|
TomH |
Open |
Flesh out the small-business scenarios, including any distinctive aspects around claims etc. |
|
Quorum was reached.
Brian Armstrong is based in Victoria, BC, Canada. He's involved in electronic health record implementations; he built a university portal for this that managed access to records by professionals. He's done some work with HL7. He works on problems of health data interoperability and access management.
Minutes of 2010-03-10 meeting APPROVED.
Some policies may cause the AM to ask the requester to convey some claims. We're hopeful that our current lexicon (and spec terminology section) discuss claims in a helpful and non-confusing way. The "terms negotiation" scenarios in the Scenario document probably need to be rewritten to avoid the word "terms", since we mean it in the legal sense but haven't defined it properly. We will prefer something like "policies that demand claims". Eve thinks the Scenarios doc probably could use a heavy edit to conform to all of our settled terminology.
We're lining up our ducks to provide all necessary input to the OAuth meeting next week. Eve has sent several emails to the OAuth list, and Maciej is working on his related action item.
Also see Eve's new blog post on UMA directions.
Maciej is lead author on a couple of scholarly papers. One is a "poster" (two-page paper) for the IEEE Security and Privacy Symposium (event is May 17-19) and the other is a full paper (eight pages) being submitted to the Web 2.0 Security and Privacy workshop (event is May 20). We're hoping to publish the papers' content as soon as possible ourselves, regardless of their acceptance at these venues, to the extent allowed.
Eve raised an issue in the new version of the Lexicon page that relates to the new diagram, where the possible Requesting Parties are shown. Tom points out that these questions also relate to the provisioning of an access key to a Blackberry to let it see your Gmail. The big question is: If Google Calendar as a requester app is acting on behalf of Alice again, should this be seen as person-to-service sharing or person-to-self sharing? If it's the former, the demand for claims can be more meaningful; if it's the latter, claims seem pointless.
If person-to-self, is UMA overkill vs. OAuth/WRAP? What UMA offers in addition is the following; it may or may not be worthwhile depending on the use case:
The policy would be really simple in the person-to-self case; just "if it's Alice again, grant access" (proven in whatever fashion). In this case, using any WRAP user delegation profile would work (at the WRAP layer underneath UMA) for proving this, or it could be treated "autonomously", with claims proving it's Alice again provided at the UMA layer.
If person-to-service, the UMA facility for demanding claims in order to grant access adds unique value because it demands something of Google Calendar, and we hope it's powerful in empowering authorizing users.
Paul notes that if any of this subtlety and complexity were exposed to ordinary Internet users, it would be way too complex ("mom-friendly"). Even OAuth presents some complexity that users just wish away by "clicking to continue" (Allow vs. Deny). Does this suggest that the person-to-self model, which looks closest to OAuth/WRAP, will take hold? We're not sure, but want to experiment.
Even our existing "vision wireframes" on the User Experience page may appear complex (though, in fairness, they weren't designed to be the ultimate in convenient user experiences). Eve notes that all the UX steps shown there are either one-time-only actions, or entirely optional. However, this may not be enough.
Do we need a new DP about ensuring that ease of end-user experience informs our protocol design?
Motion to add emergent DP 12: User experience: Ease of end-user experience should inform our protocol design. Motion APPROVED.
Maciej feels comfortable with the level of detail in the spec in order to begin implementation, but wants to add more examples so that it's not as dependent on the underlying WRAP spec. When his time frees up, he'll do this editing.
Eve asks about the wrap_scope parameter and whether we need more flexibility. Today, we've specified how to fill in that parameter, assuming that all anyone is doing is RESTful data setting and getting. But this parameter value may be completely inappropriate if what the requester/client side is doing is API calls ("verbs") vs. data operations ("nouns"). George comments that the session extension spec for OAuth included a way (not used in WRAP so far, it seems) to dynamically add new access capabilities into the access token being minted. If the current authorization can be passed in to the request for the new token, the new one should include all the access rights of the original one.
Tom asks whether the host-to-AM access token ever needs its scope broadened. Eve guesses that the set of actions a host can perform at the AM should be bundled together, but that the set of actions a requester can do (or the set of data it can access and do stuff with) has always been a whole sentence! (verb + noun = method + resource) But today's OAuth, and similar systems, let the SP (or AS or whatever) keep state about access authorizations, and this is pretty much invisible to whatever protocol is being used. Paul suggests that if the API is exposed as a taxonomy of resources (saying "RESTful" would imply the hypertext component of being resource-oriented), then URIs would still make natural contents of the wrap_scope parameter. So should we make anyone doing XML-RPC or its moral equivalent today expose their interface as addressable resources? Paul argues yes. The resources don't strictly have to be http: or https: – it could be anything. We think this all accords with our "RESTful" design principle.
Let's think on this before the next meeting and see if it sits well with everyone.
We'll focus pretty heavily on scenarios next time, including:
N.B.: U.S. Daylight Savings Time is in force for this meeting, and UTC has correspondingly "shifted".