Re: [OAUTH-WG] DPoP followup II: confirmation style

[Filip Skokan <[e-mail]>]

Hi Brian, everyone,

implementers always have many ways to mess up if they don't follow the
normative requirements and verification steps we spell out for them in the
document - in dpop's case they could e.g. accept HMAC signed tokens with an
`oct` key.

Pushing the JWK in a JWT Access Token will also increase its size, in case
of RSA keys by a lot, we could say we recommend to use ES* or EdDSA keys
when JWT AT size is a concern but then EdDSA is not available in Web
Cryptography API and the available ES curves have some negative energy
<https://safecurves.cr.yp.to/> around them so it would feel weird
recommending them, better to stick our head in the sand for this one.

I'm in favour of leaving the confirmation style as-is.

Best,
*Filip*


On Wed, 2 Dec 2020 at 23:29, Brian Campbell <bcampbell=
[e-mail]> wrote:

> There were a few items discussed somewhat during the recent interim
> <https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth>
> that I committed to bringing back to the list. The slide below (also
> available with some typos and omitted words as slide #18 from the interim
> presentation
> <https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/slides-interim-2020-oauth-16-sessa-dpop-01.pdf>)
> is the second one. To summarize (by basically repeating the content of the
> slide): It’s been suggested that, for resource access, having the JWK in
> the header of the DPoP proof JWT makes it too easy to just use that key to
> validate the signature and miss checking the binding to the AT’s cnf/jkt
> hash, which undermines the value of doing the binding in the first place.
> As I see it, there are two options here and I'd like to gauge WG consensus
> on which to move forward with.
>
>    1. It’s fine as is (AS/RS symmetry is nice, it's the same way
>    confirmation works in MTLS/TB, and the binding check is kinda fundamental
>    to the whole thing so it's not unreasonable to expect implementers to do it)
>    2. For resource access, put the full JWK in the AT’s confirmation and
>    omit it from the proof (less error prone, no hash function needed for
>    confirmation, somewhat less data overall between the two artifacts)
>
>
>
> [image: Slide18.jpg]
>
>
>
>
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>