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