Re: [OAUTH-WG] First draft of OAuth 2.0

[David Recordon <[e-mail]>]

On Sun, Mar 21, 2010 at 8:26 PM, Eve Maler <[e-mail]> wrote:
> Selected thoughts in response:
>
> On 21 Mar 2010, at 3:51 PM, David Recordon wrote:
>
>> Thanks!  Comments inline and updated the repo
>> (http://github.com/daveman692/OAuth-2.0/commit/3193098ff45168dd0a65456334428b20215f848a).
>>
>> On Sun, Mar 21, 2010 at 12:03 PM, Eve Maler <[e-mail]> wrote:
>>> David, great stuff -- thanks for putting this together!  Here are a few comments and questions from a quick read on the plane down to Anaheim, in spec order (the weight/priority therefore varies widely).
>>>
>>> Abstract
>>>
>>> - "delegate": The use of this word seems like it's different from how it's been used in the past, e.g. in "user delegation".  It's not a big deal, but possibly confusing.
>>
>> Rephrased a bit, but someone should just rewrite the abstract to begin with.
>
> I can stab at this by Friday, if someone else doesn't get there first...

Awesome!


>>> - It would be helpful to give really concrete examples/use cases of all of the profiles in the intro, so people can determine from this single place which profiles interest them.
>>
>> Each flow starts with one or two sentences trying to describe when
>> they should be used.  I'm perfectly willing to admin that they might
>> not be complete.  Happy to accept text from anyone! (Same goes for the
>> intro.)
>
> Another item I may get a chance to play with by the end of the week.
>
>>> - I'm thinking oauth_error_reason is where UMA could define an extension that gives an error like "claims_required".  I need to sort this out with my gang, but provide it here as food for thought.  Should we be defining our own parameter instead (and if so, should this spec say something about cases where this is done by others)?  Alternatively, should this spec allow for extended error codes in some formal fashion?
>>
>> Error codes are coming up quite a bit.  In general you should rely on
>> HTTP error responses, but there are cases where they're not specific
>> enough.  I'd really appreciate a list of error reasons that
>> implementors would like to see in the protocol.  A combined list will
>> help make it happen.  Seems like we should start a thread about this.
>
> I'll raise the question of the claims_required code at the UMA meeting on Thursday, and feed back any input.
>
>>
>>> 2.5. Client Identifier and Secret Flow
>>>
>>> - "This flow is suitable when the client is also the resource owner": I think this was supposed to be the "two-legged"/"autonomous-client" solution, but this phrase throws that into doubt for me.  What was the intent here?  Note that UMA (like a lot of others) is interested in solving automated self-registration of an autonomous client at an authorization server.  (In case it's of interest, we've been trying to sort out the legal implications of parties who are *not* the resource owner seeking authorized access; this is where our "claims_required" stuff comes in.  Sometimes the client represents "itself", or rather a company or org acting on its own behalf; sometimes it represents a person different from the resource owner; etc.  See our Lexicon at http://kantarainitiative.org/confluence/display/uma/Lexicon.)
>>
>> You're right.  Can you help reword please?
>
> How about simply: "This flow is suitable when the client acts autonomously in seeking access and is thus not accessing protected resources within the context of a given end-user."

Done, thanks!


>>> - "the protected resource MUST NOT allow the user of the corresponding access token without its secret": This is a case where "[protected resource] server" would work way better than "protected resource", as resources don't allow or disallow actions; they just exist.
>>
>> hmm, does read a bit better in most cases.  Means changing the
>> definition as well.  What do others thing?
>
> (I think it's all hanging together nicely now, but I'm biased. :-)  Note that there are still some instances of "protected resource" that now want to be "server" -- I see one in the first sentence of 4.1.1, and this probably happens all over section 4.
>
> A final new comment: The spec says nothing at all about how a token gets validated, which may be fine, but given that several different means of token validation have been discussed (here and on the WRAP list of late), should something explicit be said that puts the validation method out of scope for this spec?

I think that this should remain out of scope.  As far as OAuth is
concerned the token should be opaque and up to authorization servers
and protected resource servers to choose what goes into each token.

--David


>
>        Eve
>
>        Eve
>
> Eve Maler
> [e-mail]
> http://www.xmlgrrl.com/blog
>
>