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 <[email protected]> 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 [[email protected]] on behalf of Dick Hardt [ > [email protected]] > 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= > [email protected]<mailto:[email protected]>> 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> >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
