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

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 03 Mar 2015 11:59:56 +0100

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

---

From: Justin Richer <[email-masked]>
Date: Wed, 4 Mar 2015 16:31:49 -0500

> On Mar 3, 2015, at 5:59 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Justin, Hi all,
> 

Thanks, this is more accurate.

> 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)", draft-ietf-oauth-json-web-token (work in

Good point, previous drafts didn’t reference the registry so this needs to be upgraded to normative.

> 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?

> authorization priviliges.

That seems like reasonable guidance, can you suggest text?

Thanks,
 — Justin

> 
> Ciao
> Hannes
> 
> 
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth