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

[Sergey Beryozkin <[e-mail]>]

Hi Hannes

Thanks for the clarifications, comments below...
On 02/12/14 12:02, Hannes Tschofenig wrote:
> Hi Sergey,
>
> On 12/02/2014 12:30 PM, Sergey Beryozkin wrote:
>>>
>>> * 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 ?
>>
>
> The problem is that the AS needs to have the same context as the RS. In
> the bearer token case, the RS really only needs to pass the the access
> token along but in the PoP case one could imagine a couple of different
> solutions.
>
> A possible solution is that the AS sends the RS the necessary key so
> that the RS is able to verify the MAC or digital signature covering the
> request.
>
> The story would again be different if the PoP solution involves TLS.
>
> Yet another solution would be to also forward the entire request to the
> AS (which I wouldn't do).
>
> This is not specified in the current version of token introspection and,
> from the responses Justin gave at the last IETF meeting, he does not
> want to wait till the PoP work is finished to actually work out the
> details.
>
> Finally, from a security point of view it would be extremely important
> that the AS only provides a key to the RS if the RS is (a) authenticated
> and (b) the audience field from the token matches the RS since otherwise
> the PoP security degrades to a bearer token.

I see the draft specifying an optional resource_id hint (which I read 
being an actual request URI) which is the primary signing material in 
the pop case, the extra parameters like the nonce/timestamp can be 
forwarded along.

I agree it does not make sense to forward the actual body but that is 
probably going to be a very rare case where a body hash is also provided.

Explicitly disallowing the support for the pop tokens in the 
introspection text might the interoperability reach of either pop tokens 
or token introspections in cases where a given RS integrates with a 3rd 
party AS. May be it is a Security Considerations draft issue which would 
make it more open for pop tokens

Thanks, Sergey

>
> Ciao
> Hannes
>
>> Thanks, Sergey
>