Two different specifications (GNAP and FAPI signatures) have recently profiled
DPoP to use its signature method to protect a different kind of protocol
entirely. One thing these methods have in common is that they both define an
additional field for holding a digest of the HTTP Message Body:
https://bitbucket.org/openid/fapi/src/master/Financial_API_Simple_HTTP_Message_Integrity_Protocol.md#markdown-header-521-htd-the-digest-of-the-http-request-or-response-body
<https://bitbucket.org/openid/fapi/src/master/Financial_API_Simple_HTTP_Message_Integrity_Protocol.md#markdown-header-521-htd-the-digest-of-the-http-request-or-response-body>
https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-03.html#name-demonstration-of-proof-of-p
<https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-03.html#name-demonstration-of-proof-of-p>
Both of these have the same semantics, and we’re changing the name in GNAP to
align with the FAPI one. This begs the question: do we want to just define this
field as an optional component in DPoP instead of having these profiles do it
separately? It would save them from needing to align with each other, and
anyone else from inventing it again.
Is it worth defining this in DPoP directly, or does that complicate the spec
too much? I’ve previously raised a similar question on including a hash of the
access token in the DPoP request to the RS.
— Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
