I completely agree Justin, as mentioned - i wondered a year ago, I don't anymore. But i'd like it to be clear that sending a DPoP proof does not necessarily mean the AS MUST issue a DPoP access token. Depending on the AS/RS relationship and configuration a regular Bearer may be still be issued and only the public client's refresh token would be constrained.
Best, *Filip* On Fri, 17 Apr 2020 at 17:16, Justin Richer <jric...@mit.edu> wrote: > The idea of “Continuing to work without taking advantage of sender > constraints” is, I would argue, a security hole. Systems are allowed to > fail security checks but still offer functionality. This is exactly the > pattern behind allowing an unsigned JWT because you checked the “alg" > header and it was “none” and so you’re OK with that. Yes, you shouldn’t do > that, but maybe we could’ve also made this more explicit within JOSE. By > using the ‘DPoP’ auth scheme, we’re making a clear syntactic change that > says to the RS “either you know to look for this or you don’t know what it > is”. > > It’s one of the problems I have with how the OAuth MTLS spec was written. > By re-using the “Bearer” scheme there, I believe we’ve made a mistake that > allows things to fall through in an insecure fashion. The same argument > against it — ease of porting existing deployments — was raised there as > well, and it won in the end. I hope we can do better this time. > > — Justin > > On Apr 16, 2020, at 4:05 AM, Filip Skokan <panva...@gmail.com> wrote: > > I'm still somewhat on the fence as to the pros and cons of using a new >> token type and authorization scheme. But the draft has gone with a new one. >> Would it have really helped this situation, if it'd stuck with "bearer"? Or >> would it just be less obvious? >> > > If we had stuck "bearer" than i wouldn't have raised this topic, since > existing RS would most likely ignore the cnf claim and the resource server > calls would continue to work, obviously without taking advantage of the > available sender check. > > As I wrote the preceding rambling paragraph I am starting to think that >> more should be said in the draft about working with RSs that don't support >> DPoP. Which isn't really what you were asking about. But maybe would cover >> some of the same ground. > > > I agree. > > The AS is the one that does the binding (which includes checking the >> proof) so I don't see how sending two proofs would really work or help the >> situation? > > > :facepalm: indeed, sorry. > > S pozdravem, > *Filip Skokan* > > > On Tue, 14 Apr 2020 at 23:39, Brian Campbell <bcampb...@pingidentity.com> > wrote: > >> Hi Filip, >> >> My attempts at responses to your questions/comments are inline: >> >> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan <panva...@gmail.com> wrote: >> >>> I've wondered about the decision to use a new scheme before >>> <https://github.com/danielfett/draft-dpop/issues/41#issuecomment-490096716> >>> but >>> this time i'd like to challenge the immediate usability of the future spec >>> for one specific case - sender constraining public client Refresh Tokens. >>> >> >> I'm still somewhat on the fence as to the pros and cons of using a new >> token type and authorization scheme. But the draft has gone with a new one. >> Would it have really helped this situation, if it'd stuck with "bearer"? Or >> would it just be less obvious? >> >> >>> >>> If at all, it is going to take time for RS implementations to recognize >>> the new `DPoP` authorization scheme, let alone process it properly. In the >>> meantime, i'd still like to have the option to bind issued public client >>> refresh tokens using DPoP without affecting the access tokens. In doing so >>> i get an immediate win in sender constraining the refresh tokens but not >>> introducing a breaking change for the RS. >>> >>> >>> - Do you see this as something an AS implementation is just free to >>> do since it's both the issuer and recipient of a refresh token? >>> >>> That's my first thought, yes. >> >> >>> >>> - Should this be somehow baked in the draft? >>> >>> I'm not sure. Do you think it needs to be? I'm not sure what it would >> say though. >> >> In such a case the AS could bind the RT to the given dpop proof and >> either not bind the AT while returning token_type=Bearer or bind the AT >> while returning token_type value DPoP. In the latter case the AT would >> almost certainly still work as a bearer token at the RS and the client that >> knew the RS's needs could send it as such with an `Authorization: Bearer >> <at>`. Or if it didn't know the RS's needs, it could start with >> `Authorization: DPoP <at>` which would get a 401 with `WWW-Authenticate: >> Bearer` at which point it could send `Authorization: Bearer <at>`. >> >> As I wrote the preceding rambling paragraph I am starting to think that >> more should be said in the draft about working with RSs that don't support >> DPoP. Which isn't really what you were asking about. But maybe would cover >> some of the same ground. >> >> >> >>> >>> - Do you think client registration metadata could be used to signal >>> such intent? >>> >>> I think it certainly could. But it seems maybe too specific to warrant >> metadata. >> >> >>> >>> - Do you think the protocol should have signals in the messages >>> themselves to say what the client wants to apply DPoP to? >>> >>> My initial thought here is no. Take the case of a client working with an >> AS that supports DPoP and one RS that does and one RS that doesn't. I can't >> really even think what signaling might look like there or how it could be >> made to be generally useful. >> >> >>> >>> - What if AS and RS don't have a shared support DPoP JWS Algorithm? >>> Do we disqualify such cases or allow for sending two proofs, one for the >>> AS >>> to bind refresh tokens to, one for the RS to bind access tokens to? >>> >>> The AS is the one that does the binding (which includes checking the >> proof) so I don't see how sending two proofs would really work or help the >> situation? >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited... >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you.* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
