> On Oct 13, 2021, at 12:26 PM, Richard Backman, Annabelle
> <richa...@amazon.com> wrote:
>
> Those issues that could be addressed without completely redesigning DPoP have
> been discussed within the Working Group multiple times. (See quotes and
> meeting notes references in my previous message) The authors have pushed back
> on extending DPoP to cover additional use cases them due to a desire to keep
> DPoP simple and lightweight. I don't begrudge them that. I think it's
> reasonable to have a "dirt simple" solution, particularly for SPAs given the
> relative limitations of the browser environment.
>
> Other issues are inherent to fundamental design choices, such as the use of
> JWS to prove possession of the key. E.g., you cannot avoid the data
> duplication issue since a JWS signature only covers a specific serialization
> of the JWT header and body.
Agreed with keeping DPoP simple, which was why I was asking if the proposal
could indicate it was targeting some of these other use cases. The current
draft being proposed for adoption I believe is fixed to the same HTTP
properties that DPoP leverages, and thus appears to be targeting the same use
cases with a different proof expression.
The duplication within the token is also a trade-off: it allows an
implementation to have a white list of acceptable internal values, if say the
host and path are rewritten by reverse proxies. It also allows an
implementation to give richer diagnostic information when receiving
unacceptable DPoP tokens, which may very well come at runtime from an
independently-operating portion of an organization reconfiguring intermediaries.
-DW
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
