Hi Justin, Hi all, here are some random review comments:
FROM:
" Since
OAuth 2.0 [RFC6749] defines no direct relationship between the
authorization server and the protected resource, only that they must
have an agreement on the tokens themselves, there have been many
different approaches to bridging this gap.
"
TO:
" Since OAuth 2.0 [RFC6749] does not define a protocol between the
authorization server and the resource server to retrieve
meta-data associated with the access token different approaches to
bridge this gap have been developed.
"
Reason: OAuth 2.0 assumes a relationship between the authorization
server and the resource server since otherwise the resource
server wouldn't be able to trust the content of the access token.
FROM:
"
The introspection endpoint MUST be protected by TLS of at least
version 1.2 RFC 5246 [RFC5246] and MAY support additional transport-
layer mechanisms meeting its security requirements.
"
TO:
"
The introspection endpoint MUST be protected by TLS of at least
version 1.2 RFC 5246 [RFC5246].
"
Reason: I have no idea what the "additional transport layer mechanisms are.
JWT is listed as an informative reference. I believe it needs to be
normative because you depend on the registry being re-used.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token (work in
progress), July 2014.
You write:
> The response MAY be cached by the protected resource.
It might be worthwhile to say that it may be cached not longer than the
lifetime of the token. It would also be good to mention that there is a
trade-off between caching and a real-time check in terms of revocation.
You write:
Specific implementations MAY extend this structure with their own
service-specific pieces of information as top-level members of this
JSON object.
Here I would add that the inclusion of non-standardized tokens need to
be based on the agreement between the authorization server and the
resource server to avoid confusion and potentially elevation of
authorization priviliges.
Ciao
Hannes
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
