> -----Original Message-----
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Justin Richer
> Sent: Wednesday, March 16, 2011 4:05 PM
> Preamble:
>
> Does this document actually obsolete 5849? Since OAuth2 is explicitly not
> backwards compatible, is this WG really making the claim that we're updating
> OAuth, or rather defining a newer (and better) way of doing it?
People considering implementing 5849 should reconsider and implement this. So
yeah.
> 1.4.2 (et al)
>
> I still don't like the word "implicit" being used here, since there's really
> nothing implicit about it. The grant being made is explicit as far as the end
> user is concerned, and could even have an intermediary "do you authorize
> this?" screen in the middle. I'm still failing to come up with a better term
> than
> the original "user-agent" wording. What we're really talking about here is a
> way for an end user to directly authorize a client as opposed to doing a
> traditional double-redirect. So it's direct like client-credentials and
> username-
> and-password, but it's on behalf of a user and the client still never sees the
> user's credentials to the AS. We need, and have needed for some time, a
> better way to say this.
Implicit as in, there isn't any string or value being issues which represents
it (as in authorization code, user password, etc.). You go from request to
access token without anything in the middle - an authorization grant.
> 2.0
>
> The phrase "extension grant types MAY define" should probably be the
> more encompasing "extensions MAY define".
The only use cases we've seen for new endpoints are from new grant types (e.g.
device flow).
> 4.1.3
>
> "Validate the client credentials and ensure they match the authorization
> code." makes it sound like the client credentials and the authorization code
> are the same, or derived from each other. Suggest: "Validate the client
> credentials and ensure that the client presenting the code is the same one
> the code was originally issued to." This phrasing also implies an architecture
> decision: access codes need to be bound to client id's.
Verify that the authorization code is valid, and that the
redirection URI matches
the redirection URI used by the authorization server to deliver
the authorization
code.
> 4.1.4 (and other flows)
>
> What's with the "example_parameter" bit in all the examples? I think we
> only need this in 5.1's example. It's confusing when peppered throughout
> the spec without context.
I refuse to use bearer tokens as examples throughout the spec (or to waste a
month talking about it), and I figured people will not be happy with using MAC
examples exclusively (except for the two in section 7). So I am using a made up
access token type 'example'. I'm happy to change it to MAC examples.
> 5
>
> This section should probably point out that the poorly-named implicit flow
> doesn't use the format in here, and that the reader should go check out
> section 4.2 instead.
It's pretty clear when you read 4.2.
> 6
>
> Do we need to say that downscoping an access token doesn't change the
> issued scope for the refresh token? It seems obvious to me, but I'm
> wondering if we want to head off questions about this behavior. In
> general, I'd still like to see an explicit section about this behavior
> apart from the (well-written) paragraph about the scope parameter.
> Particularly since we've had someone propose a rescoping proposal
> already (but I can't seem to find this in my email archives now.) I can
> propose text if the WG agrees this is of use; otherwise it probably
> belongs in developer guides.
I rather not touch the balance we have. This belongs elsewhere where scopes are
expanded into something more specific.
EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
