> On Mar 3, 2015, at 5:59 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net> > wrote: > > 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. >
Thanks, this is more accurate. > 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. > > This has been common verbiage, but after Kathleen’s comments on Dyn-Reg we probably want to adopt that block of text instead anyway, which includes the TLS BCP reference. > 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. > > Good point, previous drafts didn’t reference the registry so this needs to be upgraded to normative. > 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. It’s always a tradeoff and we can give some guidance, but we’re not going to solve cache consistency here. Can you suggest text for how to strike this balance? > > 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. That seems like reasonable guidance, can you suggest text? Thanks, — Justin > > Ciao > Hannes > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
