General comments:
Putting the flow description, diagram and steps in the section with the spec
work well.
Use of "server" term. In numerous places, the term server is used instead of
authorization server or resource server (maybe even web server). To avoid
ambiguity, I would suggest the term server is never used, and the spec is
explicit on which server is being referred to.
User authentication at AS: Suggest putting this in one section and then
referring to it in 3.5.2.1 and 3.5.3.1 (and adding into 3.5.1)
Having 5 levels of sections seems overly deep with the bulk of the document
being in 3.5 and 3.6.
Sections 4 and 5 seem weaker than the other sections. Would you like me to take
a stab at rewriting those?
2. Introduction
These resources are usually private ...
Why the use of the word "private" instead of "protected"?
Description of autonomous flow is missing.
2.1
authorization endpoint
The authorization server's HTTP endpoint capable of
authenticating the resource owner and obtaining authorization,
issuing tokens, and refreshing expired tokens.
Does the authorization endpoint issue tokens and refresh tokens? I thought that
was only the token endpoint.
client identifier
An unique identifier issued by the client to identify itself to
the authorization server. Client identifiers may have a
matching secret.
Why does the client identifier have to be issues by the client? Could it not be
issued by the AS?
Why are verification code, user code, device code not defined?
2.2
access token (or under revoked), the authorization server should
Typo
access token (or until revoked), the authorization server should
3
In many cases it is desirable to issue access tokens with a shorter
lifetime than the duration of the authorization grant. However, it
is undesirable to require the resource owner to authorize the request
again. Instead, the authorization server issues a refresh token in
suggested change:
In many cases it is desirable to issue access tokens with a shorter
lifetime than the duration of the authorization grant. However, it
may be undesirable to require the resource owner to authorize the request
again. Instead, the authorization server issues a refresh token in
3.3
In WRAP we had a section entitled Parameter Considerations where many errata
about parameters was contained.
3.5
User delegation flows are used to grant client access to protected
resources by the end user without sharing the end user credentials
(typically a username and password) with the client. Instead, the
end user authenticates directly with the authorization server, and
grants client access to its protected resources.
suggested change:
User delegation flows are used to grant client access to protected
resources by the end user without sharing the end user credentials
(such as a username and password) with the client. Instead, the
end user authenticates directly with the authorization server, and
grants client access to its protected resources.
3.5.1
Why does the user not have to authenticate to the AS in this flow?
3.5.1.2
It is unclear to me how to make the user-agent NOT include the fragment.
3.5.3
The terms for the different codes is not consistent. client code, client
verification code, device code, device verification code
3.5.3.5.1
If the end user authorized the request, the authorization server
issues and access token and delivers is to the client by including it
typo:
If the end user authorized the request, the authorization server
issues an access token and delivers is to the client by including it
3.5.3.2.3
Great to have all the different error conditions. Spec should discuss what the
client should do for each error code.
3.7.1 and 3.7.2 (diagrams 7 & 8)
Need to add
(w/ Optional Refresh Token)
to be consistent with other diagrams and that refresh is optional in all calls
3.7.2.1
format parameter. Not sure why this undefined parameter is ok, but scope is
not! :)
The example needs a little fleshing out. :)
4.
While the section introduction describes how it can be used to obtain tokens
with different security parameters and getting a secret, how and when the
developer would make different calls is unspecified.
The following statement is not always possible:
The authorization server MUST invalidate the old access token being
replaced.
If the access token is self contained, then the authorization server cannot
invalidate it.
5.1
The "Authorization" request header field is used by clients to make
both bearer token and cryptographic token requests.
This statement implies that this is the only way to make requests. Perhaps
introduce section 5 by clearly stating there are different mechanisms for
transporting the access token?
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
