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 would agree with keeping DPoP simple if it meant that 99% of problems were solved, in which case the question would be why do we need this RFC, and if what is here is so common, then what good is the DPoP one? Simple is useless if it is never used. If there are really so many cases, then I think we need to focus on recreating PoP in an extensible way that allows the DPoP to sit on top, and other RFCs to be layered in without a bunch of RFCs to all have competing semantics. Here's a great example. I think having an additional header is unjustified, DPoP, Signature, or whatever you want to call it. But the only thing more unjustified than that is having different headers for different implementations of PoP. We can start with a new Draft that just says, PoP header is X, end of story, might as well call it *Authorization-Extra-Info*, and then layer in what you want in there. Then the number of differences through these refactoring between these two drafts becomes smaller. Surely we can agree to a draft that contains only the semantics that are the same between the existing two, and then reuse the same terminology and the same implementation, header name, etc... We definitely need a PoP RFC, there's no question there (at least I don't think there is), so let's start with the subset of all pieces that both sets of authors can agree to. Is this the list of current concerning limitations? > > 1. Does not support symmetric keys. > 2. Requires the same key to be used with AS and RSes. > 3. Does not support multiple valid signing keys. > 4. Signed content is copied into the JWT and therefore duplicated > within the message. This allows for bugs where the verifier fails to check > that these values match, or performs that check incorrectly. (e.g., > assuming case insensitivity) > 5. Only covers the method, scheme, host, and path. Allows for > additional arbitrary content to be signed, but does not provide any > guidance or support for defining interoperable extensions. > 6. Depends on JWT, which may be a new dependency, particularly for > clients that are doing OAuth 2.0 but not OIDC. > > Can we narrow this down to the non-negotiables? For instance surely (1), (4), (6) aren't that bad, sure they may not be optimal for every case. I can (2) & (3) to be actually limiting and (5) to be easy to allow extensibility. Would your concerns be at least somewhat be mitigated by allowing for solutions regarding (2) & (3)? Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Wed, Oct 13, 2021 at 8:41 PM David Waite <david= 40alkaline-solutions....@dmarc.ietf.org> wrote: > > > > 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
