push token delivery + sender constrained/proof of possession

[Joseph Heenan]

As far as I can see there’s no mechanism documented to use MTLS certificate bound access tokens with the push token delivery mode, meaning you can’t use push if you’re following the oauth security BCP. (Similarly I don’t think there’s any documented way for DPoP or any other similar mechanism to work.)

This may at least be worth mentioning under security considerations?

It seems like it would be possible to support it - it would require the relevant info to be presented at the backchannel authentication endpoint when initiating the request, though particularly for long lived requests presenting the constraining info that early could cause issues if the RP wishes to rotate keys.

[Brian Campbell]

Indeed the nature of the extensions that enable PoP tokens like MTLS (now RFC 8705) and DPoP (now in a call for adoption in the WG) are to do the key presentation and proof and binding at the token endpoint. It’s a natural and consistent place for the addition of such functionality but doesn’t account for variations that issue tokens in unorthodox ways like CIBA’s push mode. Personally I pushed for the push mode to be removed from CIBA all together but some folks wanted to keep it. So it remained. But I definitely don’t want to try and slap in awkward support for MTLS or other similar approaches like DPoP into CIBA itself to try and allow for it via push. It’s ugly and problematic for a whole host of reasons. The inability to PoP constrain tokens in the push mode was one reason (though not the only) that the FAPI CIBA profile disallowed push. I guess where I’m going with this rambling mini rant is that we could certinally add something about this to security considerations, if you think that’d be helpful? And I’d weclome any text you’d like to propose.

‌

[Dave Tonge]

I agree about adding some text to the security considerations

[Brian Campbell]

Pull Request #78 aims to address this by adding the text quoted below to the security considerations section.

OAuth 2.0 extensions that facilitate so called proof-of-possession (PoP) or sender-constrained tokens, such as [RFC8705] or [I-D.fett-oauth-dpop], work by way of the client presenting and proving possession of a key when making a request to the token endpoint and the authorization server issuing tokens bound to that key. CIBA's push mode cannot be used to acquire such PoP tokens in a standard and interoperable manner because the normal method of issuing tokens via the token endpoint is bypassed. Implementations and deployments that might require PoP tokens, such as those conforming to the recommendations in [I-D.ietf-oauth-security-topics], are therefore discouraged from using the push mode.

‌

[Brian Campbell]

merged pull request #78 af031a4868b0