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