Am 11.06.20 um 23:17 schrieb Brian Campbell: > > Also to help facilitate mixed or rollout deployments, I'm not sure > about "An client should never send a DPoP [bound access] token as a > Bearer header." Such a constraint could be put on the client but it > seems unhelpful. A bad acting client could easily ignore it and I'm > not sure what it accomplishes if/when followed. Following from > https://github.com/danielfett/draft-dpop/issues/58 the draft needs to > be updated to say explicitly that an RS supporting both Bearer and > DPoP schemes simultaneously needs to update its Bearer token > evaluation functionality so as to reject tokens that are dpop bound. > But the draft can't really impose anything on existing RSs supporting > only Bearer (and unaware of DPoP). And such RSs will most likely > accept a DPoP bound AT when send via the Bearer scheme (JWT says to > ignore unrecognized claims, introspection says other parameters might > be present, and 6750 is basically silent on the content of the AT, > which is where the binding is carried). This admittedly doesn't seem > quite right. But there's nothing this draft can realistically do about > it. And I think it can help with mixed or rollout deployments. > Especially those where sufficient information about what RS(s) the > requested token is for are not available in the token request for > whatever reason. Currently the draft is silent about it and maybe > that's as it should be. But I'm suggesting in a few messages on this > thread that the definition of the DPoP token_type would prescribe > sending the access token with the DPoP authorization scheme in > conjunction with the DPoP header but also say that, if that was met > with a 401 WWW-Authenticate: Bearer challenge by a particular RS (or > the client had prior such knowledge about the RS), that the access > token could be sent using the Bearer authorization scheme. I would support that. > > It is correct that, as currently written in the draft, a public client > with a DPoP bound refresh token will have to use the same key for the > lifetime of the grant. That seemed like a good tradeoff vs. defining a > mechanism for key rotation for the public client refresh token case > where two proofs (one to verify the binding for the RT being sent and > one to newly bind the RT to) would be presented on refresh grant type > request. I tend to think where it is now hits the right balance in > functionality and complexity. But if there are strong beliefs > otherwise, let's discuss the need and cost/benefit and all that.
Absolutely agree. We would create a lot of complexity for very little gain. -Daniel -- https://danielfett.de
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
