Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Dick Hardt <[e-mail]>]

Thanks for pointing out the Oblivious draft Justin. It is interesting, but
looks to be focussed on privacy rather than non-repudiation. Was I missing
non-repudiation aspects?
ᐧ

On Sat, Oct 23, 2021 at 4:55 PM Justin Richer <[e-mail]> wrote:

> Dick, you would probably be interested in the Oblivious HTTP effort that
> has recently been chartered to solve similar encapsulation problems in
> HTTP.
>
> - Justin
> ________________________________________
> From: OAuth [[e-mail]] on behalf of Dick Hardt [
> [e-mail]]
> Sent: Friday, October 22, 2021 6:08 PM
> To: Richard Backman, Annabelle
> Cc: David Waite; oauth
> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth
> Proof of Possession Tokens with HTTP Message Signature
>
> 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=
> [e-mail]<mailto:[e-mail]>> 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.
>
> [
> https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=593dd17a-bb93-449b-8126-3b72052d76b2]ᐧ
> <https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=593dd17a-bb93-449b-8126-3b72052d76b2]%E1%90%A7>
>