Hi Sergey, comments below.
On 12/02/2014 01:39 PM, Sergey Beryozkin wrote: > 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. Of course we haven't worked out the details for the HTTP signing yet. Hence, it would be a bit premature to make that conclusion. > > 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. Maybe. I see a lot of value in protecting the body of the message as well but I would do it with the help of TLS and then use a channel binding mechanism. > > 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 Ultimately, we are really only talking about a document management issue here. I assume that we want to have support for introspection with PoP tokens as well and we might just end up dumping the text into the HTTP signing draft (as an extension to the token introspection doc). Ciao Hannes > > Thanks, Sergey > >> >> Ciao >> Hannes >> >>> Thanks, Sergey >> > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
