[WG-UMA] Agenda for focus meeting to be held shortly (diff dial-in!)
0 views
Skip to first unread message
Eve Maler
Aug 2, 2010, 9:48:06 AM8/2/10
to WG UMA
Monday, 2 Aug 2010, 7-8am PT (time chart)
Teleconference Info:
- Skype: +9900827044630912
- North American Dial-In: +1-201-793-9022
- Room Code: 4630912
1. Dynamic registration (edited draft in XML; HTML version attached to this email)
- Native-app flow for dynamic client registration: Maciej flow and latest Domenico(+Eve) flow
- Other changes needed?
- Other edits required?
2. Resource registration (HTML draft attached)
- Review in general
- See TODOs list: there are some big questions on there
- Big issues as characterized by our last WG meeting:
- Resource details protocol
- Push (Christian's draft)
- Pull (Maciej's experimental method)
- Resource details format
- Just resources, resource groups, and so on
- Scopes: combination of resources/endpoints and what you can do with them
Eve
Eve Maler
Aug 2, 2010, 11:05:38 AM8/2/10
to WG UMA
Attending: Eve, Kevin, Domenico, Nat, Maciej
On 2 Aug 2010, at 6:48 AM, Eve Maler wrote:
Monday, 2 Aug 2010, 7-8am PT (time chart)FOCUS GROUP DIAL IN:
Teleconference Info:
- Skype: +9900827044630912
- North American Dial-In: +1-201-793-9022
- Room Code: 46309121. Dynamic registration (edited draft in XML; HTML version attached to this email)- Native-app flow for dynamic client registration: Maciej flow and latest Domenico(+Eve) flow- Other changes needed?- Other edits required?
Do we actually need the issued_at? OAuth doesn't have it, and it still has the expires_in parameter. Nat explains that expires_in makes no sense without issued_at if you are using a protocol that has any latency in it at all. If the protocol is pretty much bulletproof in this respect, then you don't really need issued_at. We agreed to keep both, and also keep their required/optional wording, and let the OAuth group discuss it. OK.
Eve's latest edit to Domenico's diagram adds three asterisked items, reflecting a requester-oriented flow. Without them, it could serve as a host-oriented flow. Regarding the very last step, how would the AS provision the native app with credentials? Nat suggests that something like a notification service would typically be used.
Nat asks whether there is supposed to be a Dev.com->MobileApp interaction after the latter's authentication cycle. If Dev.com can return a signed value to MobileApp ahead of time with which Dev.com prepares some metadata uniquely for it, then MobileApp could approach the AS as in Maciej's flow.
Nat will try to do a hybrid flow that we can include in the draft, as a TODO (even if we submit it in that form). Eve will add a third type parameter value for this, called "native-app".
Regarding how to handle signing in the push and pull cases, Nat thinks we can just refer to the OAuth signature solution rather than including precise wording.
Should we mention that the pull scenario requires that the AS correlate the domain of the approaching client with the supplied client_url? This is, in fact, a security consideration. The key thing that makes "pull" more secure is this check. Nat will find some wording on this. OK.
Is the propagation problem improved? We believe so, as long as the client is pushing a URL to the same server that's going to do the pull.
We should probably add HTTP POST examples where necessary. OK.
Which endpoints should require HTTPS? We need to require that endpoints use HTTPS or that the request message to it be signed, and we need to add a security consideration saying that we expect this to be profiled down (e.g. to require both) for higher assurance. OK.
2. Resource registration (HTML draft attached)- Review in general- See TODOs list: there are some big questions on there- Big issues as characterized by our last WG meeting:
- Resource details protocol
- Push (Christian's draft)
- Pull (Maciej's experimental method)
- Resource details format
- Just resources, resource groups, and so on
- Scopes: combination of resources/endpoints and what you can do with them
We need to add an example of how the AM POSTs (or GETs?) the resource information document from the host's resource information URL. The big question for us today is: Is this URL protected? And if so, what token does the AM wield there, and how did it acquire the token? We don't think the AM could wield the exact same access token that it had given the host as a "host access token". How sensitive is the resource information document, in fact? Perhaps, if the URLs in question could all be one-time-use only, or could be mutually AM-specific and host-specific, this could provide security a different way. We observe that if we could figure out "bilateral OAuth" where each side gets a token to use with the other, then full push and pull become possible in all sorts of use cases. Note that resource registration needs "true pull", vs. the situation in client registration where it's "push-then-pull". No firm conclusion here.
Eve has proposed a couple of "scopes" parameters. The idea is that the AM, without knowing the semantics at all, could provide dropdowns and other handy UX elements to help users craft policies that take advantage of the possible actions. If method keywords get standardized, this becomes even more interesting. She's now thinking, however, that it should be called "actions", or even "methods" as used in the current/old UMA core spec draft, because OAuth's use of the word "scope" refers to a very high-level (and non-standard) bundle of resource URLs (OAuth-protected API endpoints) and methods (not HTTP methods necessarily). Maciej notes that we get into very interesting questions of semantics in delving into the entire scope issue.
Maciej will try to review this draft carefully before Thursday.
Reply all
Reply to author
Forward
0 new messages