Many of my comments have probably been covered by other folks on the
list, but I'm going to repeat things along here anyway:
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?
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.
2.0
The phrase "extension grant types MAY define" should probably be the
more encompasing "extensions MAY define".
2.1
The wording on implicit and explicit makes even less sense here, since
if the client is getting back a token directly then the grant is even
more explicit than if the client has to trade the code for something.
Think about it this way: if the AS is giving you a code, it's implied
that that code is good for you to get a token that you can actually do
something with. The AS hasn't actually granted the client access to the
PR yet, though, just provided a means for doing so. On the other hand,
the client that gets a token directly is being granted explicit access
to the PR directly. The server's not implying anything here, it's saying
"hey, go get stuff with this token".
3.
With 'client_id' required on most steps, the phrase that the AS should
not issue credentials to untrustworthy clients is incongruous. Perhaps
better would be to say that the AS shouldn't trust the credentials
issued to clients without the ability to keep secrets. Basically, we
need a way of saying that the client identifier is necessary but the
assumption of it being kept a secret can only go so far. I'm sure the
security considerations will cover this more deeply, but this is
something that should be clarified up front here, especially because
this section is referenced throughout the document.
4.1.2 (and other flows)
Rephrase: "The clients should avoid making assumptions about code value
sizes. The authorization server should document the size of any value it
issues." as "Clients should avoid making assumptions about code value
sizes, and the authorization server should document the size of any
value it issues."
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.
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.
4.2
Remove "or native applications", add language about the saved
round-trip, which is the real reason for this flow, not security
concerns over saved secrets. Javascript clients could easily use the
auth code flow with their security profile (and an untrusted client
password, which is allowed).
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.
5.2
Provide a mechanism for extensions to put different error codes onto the
wire, either through a registry, URIs, or language saying how to update
this RFC.
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.
Overall, -13 is in decent shape, and modulo a little polishing as
enumerated here it's basically ready, in my opinion.
-- Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
