> On Oct 14, 2021, at 8:47 AM, Warren Parad <wparad=40rhosys...@dmarc.ietf.org> > wrote: > > I feel like there are a bunch of pieces of the implementation fundamentally > missing here, so we are back to, as it is right now, the draft isn't > sufficient.
Of course the draft isn’t sufficient for publication — that’s what the call for adoption is all about! It’s not meant to say “this is done, let’s ship it”, it’s meant to say “this is an idea, let’s finish it in the WG”. > What prevents the signature from being used without this RFC? I’m not sure what you’re asking here. HTTP Message Signatures can be used without the OAuth-specific RFC. Someone could also use HTTP Signatures with OAuth tokens without following anything from the OAuth WG. There are people doing that today in the wild, using the predecessors of the HTTP Message Signatures draft and their own grafting. > How do you do expect the symmetric key exchange to be oauth compliant? I can think of a number of approaches that would work: Pre-registration of keys, key derivation functions, cloud key escrow systems — these are things that the OAuth profile of HTTP Signatures would have to answer, as I laid out in my presentation. > How does the RS know that there is supposed to be a signature, if the client > doesn't provide it? The same way that it knows there’s supposed to be a particular MTLS certificate or DPoP Proof today — the token metadata. The RS can get that through introspection, through something in the token itself (like the JWT “cnf” claim), or some other internal system. — Justin > > > 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 11:55 PM Richard Backman, Annabelle > <richa...@amazon.com <mailto:richa...@amazon.com>> 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. > > >> 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. > > This is what we are doing with Message Signatures. We're providing a general > purpose signature mechanism, which higher-level protocols can build on. > > >> 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. > > I can see the argument for DPoP including the proof in the `Authorization` > header field, since the proof is intrinsically related to the access token > and request authorization – not making a judgement on that, as this is the > wrong thread and I don't have a horse in that race. Packing everything into a > single header field doesn't make sense for Message Signatures, since they may > or may not have anything to do with request authorization, access tokens, or > anything of the sort. Additionally, the use of separate `Signature-Input` and > `Signature` header fields allows us to have a very simple field syntax using > Structured Field Values for HTTP > <https://datatracker.ietf.org/doc/html/rfc8941>, and makes it easy for > intermediaries to chain signatures. (E.g., a reverse proxy might add an > `X-Forwarded-For` header field, and add a Message Signature covering that > header field plus the PoP signature included by the client.) …and I'll stop > there lest we dive into topics for the HTTPbis WG. > > — > Annabelle Backman (she/her) > richa...@amazon.com <mailto:richa...@amazon.com> > > > > >> On Oct 13, 2021, at 12:01 PM, Warren Parad <wpa...@rhosys.ch >> <mailto:wpa...@rhosys.ch>> wrote: >> >> CAUTION: This email originated from outside of the organization. Do not >> click links or open attachments unless you can confirm the sender and know >> the content is safe. >> >> >> 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? >> Does not support symmetric keys. >> Requires the same key to be used with AS and RSes. >> Does not support multiple valid signing keys. >> 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) >> 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. >> 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 >> <mailto:40alkaline-solutions....@dmarc.ietf.org>> wrote: >> >> >> > On Oct 13, 2021, at 12:26 PM, Richard Backman, Annabelle >> > <richa...@amazon.com <mailto: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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
