Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

[Sergey Beryozkin <[e-mail]>]

Hi Hannes
On 02/12/14 11:23, Hannes Tschofenig wrote:
> 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.
>
Interesting, I was reading the doc yesterday and thought it was good it 
was not talking about specific access token types :-)

I wonder why a pop token can not be introspected in the interoperable 
way as per the text for the resource server to tale the authorization 
decision ?

Thanks, Sergey

> * 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
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>