<hat type='AD'/> On 3/2/11 1:31 AM, Hannes Tschofenig wrote: > This is a Last Call for comments on > > http://www.ietf.org/id/draft-ietf-oauth-v2-bearer-03.txt > > Please have your comments in no later than March 25 (extended deadline > because of the ongoing OAuth base specification WGLC). > > Do remember to send a note in if you have read the document and have no > other comments other than "its ready to go" - we need those as much as we > need "I found a problem". > > Thanks! > Hannes & Blaine
I agree with much of the last call feedback that other folks have
provided. Here are some additional comments.
1. It would be helpful to define "bearer token" in the introduction
because this term is not defined in RFC 4949 or the base OAuth spec.
2. Please cite RFC 2617 when mentioning the "Authorization" request
header in Section 2.
3. Some of the conformance language is confusing, e.g. the construction
"SHOULD only X if Y" is better as "SHOULD NOT X unless Y".
For example (Section 2):
Clients SHOULD only use the request body or URI when the
"Authorization" request header field is not available, and MUST NOT
use more than one method to transport the token in each request.
Because of the Security Considerations (Section 3) associated with
the URI method, it SHOULD only be used if no other method is
feasible.
That is better as:
Clients SHOULD NOT use the request body or URI unless the
"Authorization" request header field is not available, and MUST NOT
use more than one method to transport the token in each request.
Because of the Security Considerations (Section 3) associated with
the URI method, it SHOULD NOT be used unless no other method is
feasible.
In Section 2.2:
The client can use this method only if the
following REQUIRED conditions are met:
That is better as:
The client MUST NOT use this method unless the
following conditions are met:
In Section 2.2, I think you mean "MUST NOT" instead of "MAY NOT" here:
o The HTTP request method is one for which a body is permitted to be
present in the request. In particular, this means that the "GET"
method MAY NOT be used.
In Section 2.2, I think you mean "SHOULD NOT ... unless" here:
The "application/x-www-form-urlencoded" method should typically only
be used in application contexts where participating browsers do not
have access to the "Authorization" request header field.
In Section 2.3, I think you mean "SHOULD NOT ... unless" here:
Because of the Security Considerations (Section 3) associated with
the URI method, it SHOULD only be used if no other method is
feasible.
In Section 2.4.1, change "SHOULD not" to "SHOULD NOT".
4. For the ABNF in Section 2.1, please reference the "auth-param" rule
from RFC 2617. (However, I tend to agree with Eran that extensibility is
not particularly necessary here, and that some justification and
description of the extensibility mechanism is needed.)
5. I'll post separately about the error registry mentioned in Section 2.4.1.
6. It's nice to see the security considerations about attacks on tokens.
Perhaps we need a similar section in the SAML-bearer spec.
7. Please provide a reference to RFC 5246 for TLS.
8. What is the basis for defining "short-lived" a lifetime less than one
hour? That's plenty of time in which to launch an attack.
9. Regarding identity verification of resource servers, please reference
either RFC 2818 or draft-saintandre-tls-server-id-check.
10. In Section 4.1.1, I would agree with other WG participants that use
of "oauth_token" here is problematic.
11. Why is Section 4.2 on the OAuth Parameters Registry in this
document? It's already defined in the base spec.
12. Regarding Section 4.3, I'll post separately about an OAuth Errors
Registry, but if it's defined it would belong in the base spec, not here.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
