Re: [OAUTH-WG] Token Introspection: Misc Review Comments

[Justin Richer <[e-mail]>]

> On Mar 3, 2015, at 5:59 AM, Hannes Tschofenig <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth