Hi Justin, I have a few remarks regarding version -01 of the token introspection document.
* Terminology The token introspection protocol is a client-server protocol but the term "client" already has a meaning in OAuth. Here the client of the token introspection protocol is actually the resource server. I believe it would make sense to clarify this issue in the terminology section or in the introduction. Maybe add a figure (which you could copy from Figure 4 of http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. Maybe you want to call these two parties, the introspection client and the introspection server. * Scope I think the document needs to be very clear that is only applicable to bearer tokens (and not to PoP tokens). This issue was raised at the last IETF meeting as well. * Meta-Information You have replicated a lot of the claims defined in https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 and I am wondering why you have decided to not just re-use the entire registry from JWT? If you want to create a separate registry (which I wouldn't recommend) then you have to put text into the IANA consideration section. When you write: " The endpoint MAY allow other parameters to provide further context to the query. " You could instead write that the token introspection MUST ignore any parameters from the request message it does not understand. Of course, there is the question whether any of those would be security critical and hence ignoring them would cause problems?! * Security The requirement for authenticating the party issuing the introspection request to the token introspection endpoint is justified in the security and the privacy consideration section. The security threat is that an attacker could use the endpoint to testing for tokens. The privacy threat is that a resource server learns about the content of the token, which may contain personal data. I see the former as more dangerous than the latter since a legitimate resource server is supposed to learn about the authorization information in the token. An attacker who had gotten hold of tokens will not only learn about the content of the token but he will also be able to use it to get access to the protected resource itself. In any case, to me this sounds like mutual authentication should be mandatory to implement. This is currently not the case. On top of that there is single technique mandatory-to-implement outlined either (in case someone wants to use it). That's in general not very helpful from an interoperability point of view. Yet another thing to agree on between the AS and the RS. * SHOULDs This is my usual comment that any SHOULD statement should give the reader enough information about the trade-off decision he has to make. When should he implement something and when should he skip it? * Minor items You write: " These include using structured token formats such as JWT [JWT] or SAML [[ Editor's Note: Which SAML document should we reference here? ]] and proprietary inter-service communication mechanisms (such as shared databases and protected enterprise service buses) that convey token information. " Just reference the JWT since that's what we standardize. * 'Active' claim you write: " active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The authorization server determines whether and when a given token is in an active state. " Wouldn't it make more sense to return an error rather than saying that this token is not active. * Capitalization Reading through the text I see bearer token/Bearer Token, Client/client, etc. issue. * AS <-> RS relationship You write: " 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. " I am not sure what you mean by "defines no relationship" between the AS and the RS. Of course, there is a relationship. The AS issues tokens for access for a specific RS. The RS needs to understand the tokens or if it does not understand them it needs to know which AS to interact with to learn about the content. In a nutshell, I am not sure what you want to say with this paragraph particularly since you state that they have to have an agreement about the tokens. Ciao Hannes
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
