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 [oauth-boun...@ietf.org] on behalf of Dick Hardt [dick.ha...@gmail.com] 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=40amazon....@dmarc.ietf.org<mailto: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. [https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=593dd17a-bb93-449b-8126-3b72052d76b2]ᐧ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
