Quick feedback... On 4 Mar 2010, at 5:42 PM, Dick Hardt wrote:
> Hi Eve > > Looking at the WRAP oriented comments in the spec, here are some comments / > questions: > > Note > WRAP doesn't seem to say HTTPS is required for the user authorization URL; is > this a bug in the WRAP spec? If not, is it a good idea for us to profile it > in this way? Finally, is this the right place to say HTTPS is required for > all these URLs? > > Dick: an HTTPS requirement is prohibitive at times. See > http://groups.google.com/group/oauth-wrap-wg/browse_thread/thread/821e73bcbd8033dd?hl=en# > for a recent discussion on this. > Okay. > Note > Need lots of examples for all of this. Also, note that WRAP forces clients to > use POST on access token URLs and refresh token URLs; can we use GET in the > way described here? > > Dick: why do you want GET? There are security issues with using GET to the AS. We can probably do away with the GET we have, I'm guessing. We'll discuss. > > Note > Obviously this is just the highest-level sketch of what needs to happen! This > needs to be fleshed out. (E.g., the wrap_scope format could be reused here, > without any wildcards.) > Also, are we concerned that a malicious host could lie about the attempted > resource and method? The only consequence seems to be "false negatives" in > managing authorized access, in which case the user would get unhappy pretty > quickly. > > Dick: it was envisioned that the scope of a function of scope would be > embedded in the Access Token. Or perhaps I don't understand the issue. I can see three places a description of scope may need to appear. 1. Initial request for token sent by client/requester to AM/AS, so that the right kind of token can be created - this presumably has to be in-band in the protocol. (This is why there's a wrap_scope parameter on the request and nowhere else, right?) This is what we defined it in the proposed UMA step 2. 2. In the token itself. Indeed this is out of band of the protocol itself. 3. If the protected resource/host outsources token validation (such that the token is opaque to the host as well as the client/requester), then the host would need to supply a description of the attempted access made by the client/requester along with sending the token for validation. The note you're responding to just above is this third case. Eve > > > On 2010-03-04, at 11:01 AM, Eve Maler wrote: > >> Folks may be interested to see the following experiment being performed in >> the UMA group: >> >> http://kantarainitiative.org/confluence/display/~xmlg...@idp.protectnetwork.org/Proposal+for+UMA+1.0+Core+Protocol >> >> This is a proposal for a spec that uses a WRAP-friendly approach to solving >> our use cases. Please note the final comments in today's UMA telecon >> minutes for cautions about additional requirements we have: >> >> http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2010-03-04 >> >> Eve >> >> Eve Maler >> e...@xmlgrrl.com >> http://www.xmlgrrl.com/blog >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
