I have a use case for a self contained request that can be
independently verified by multiple parties. IE, not just have PoP at HTTP
endpoint, but by components doing processing further down the line. It also
provides non-repudiation.

For example, a JWT that is sent as an HTTP payload includes the request and
the access token.

mTLS, DPoP, and HTTP signing don't provide this functionality

It is not clear if others have similar requirements, or if there is value
in standardization effort, but I wanted to call out a use case not solved
by the current efforts.

/Dick

On Wed, Oct 13, 2021 at 2:55 PM Richard Backman, Annabelle <richanna=
40amazon....@dmarc.ietf.org> wrote:

> If keeping DPoP simple means we have to have come up with 10 different
> variants to handle all the different cases that it doesn't support, then it
> isn't keeping it simple, it is just pushing the problem forward to the
> implementers to figure out which set of RFCs to implement.
>
>
> I'm hoping we can stop at 3: mTLS, DPoP, and Justin's draft. If someone
> has use cases that aren't covered by one or more of those, they should
> bring those up so we can discuss them and decide what changes are
> warranted. (Either here, or in HTTPbis if changes should be made to Message
> Signatures) My preference would've been to stop at 2, but the consensus has
> not been in favor of expanding the scope of use cases served by DPoP.
>
> ᐧ
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to