I do not support adoption. While I love the idea to be able to restrict the usage of the access token by the client, enabling longer expiry access tokens, and preventing usage to perform unexpected actions with that token, the reasons I do not support the adoption are as follows:
* The draft depends on another draft and personally not one that I even agree with. Saying that the "draft is officially adopted" doesn't justify depending on it. * I reject the use of an additional header to transmit additional authorization information. Due to the nature of this information may be conveyed and stored throughout a number of systems which would all need access to this complexity. As headers and authorization evolves the introduction and replacement of existing headers provides additional security vulnerabilities. * The draft does not support multiple clients with access to the access token who all should be able to provide different client signatures and all be verifiable by the RS. * This forces the RS to lookup two pieces of information in the case of signed JWTs, the JWKs from the AS and the JWKs from the client * The argument in the introduction is flawed Bearer tokens are simple to implement but also have the significant > security downside of allowing anyone who sees the access token to use that > token. This is not a complete argument because I can replace the words in the sentence and justify that HTTPSig should never be used by the same argument: > HTTPSig tokens are incredibly complex to implement but also have the > significant security downside of allowing anyone who sees the access token > and signature to use that token. We need to come up with a better argument such as: *This allows a client to reduce use of the token to a smaller window to where the signature is also valid.* That would allow us to better focus on the value that the RFC would provide, rather than getting stuck with arbitrary implementation of another RFC draft as it would apply to OAuth. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Thu, Oct 7, 2021 at 11:03 AM Denis <denis.i...@free.fr> wrote: > I am not supportive of adoption of this document by the WG *at this time*. > > As I said during the last interim meeting, at this time, there is no > security considerations section, nor a privacy considerations section. > > The current draft describes a mechanism but does not state how the signing > key will be established and / or come from. > > From a security considerations point of view, if the client has the > control of the private key, it might be able to voluntary transmit > the private key to another client in order to mount a client collaborative > attack. If the client is unable to transmit the private key > to another client in order to mount a collaborative attack, it might be > able to perform all the cryptographic computations that > the other client needs. It is important to state which protections (or > detection) features will be obtained as well as which protections > (or detection) features will not be obtained. A top-down approach is > currently missing. > > From a privacy considerations point of view, if the same public key is > used to sign the messages whatever the RS is, this will allow > different RSs to link the requests from the same client. It is important > to state which protections (or detection) features will be obtained > as well as which protections (or detection) features will not be obtained. > > Let us wait to have both the security considerations section and the > privacy considerations section written, > before adopting this draft as a WG document. > > Denis > > Remember token binding? It was a stable draft. The OAuth WG spent a bunch > of cycles building on top of token binding, but token binding did not get > deployed, so no token binding for OAuth. > > As I mentioned, I think Justin and Annabelle (and anyone else interested) > can influence HTTP Sig to cover OAuth use cases. > > /Dick > > ᐧ > > On Wed, Oct 6, 2021 at 2:48 PM Aaron Parecki <aa...@parecki.com> wrote: > >> This actually seems like a great time for the OAuth group to start >> working on this more closely given the relative stability of this draft as >> well as the fact that it is not yet an RFC. This is a perfect time to be >> able to influence the draft if needed, rather than wait for it to be >> finalized and then have to find a less-than-ideal workaround for something >> unforeseen. >> >> Aaron >> >> On Wed, Oct 6, 2021 at 2:25 PM Dick Hardt <dick.ha...@gmail.com> wrote: >> >>> I meant it is not yet adopted as an RFC. >>> >>> To be clear, I think you are doing great work on the HTTP Sig doc, and a >>> number of concerns I have with HTTP signing have been addressed => I just >>> think that doing work in the OAuth WG on a moving and unproven draft in the >>> HTTP WG is not a good use of resources in the OAuth WG at this time. >>> >>> >>> ᐧ >>> >>> On Wed, Oct 6, 2021 at 2:20 PM Justin Richer <jric...@mit.edu> wrote: >>> >>>> > HTTP Sig looks very promising, but it has not been adopted as a draft >>>> >>>> Just to be clear, the HTTP Sig draft is an official adopted document of >>>> the HTTP Working Group since about a year ago. I would not have suggested >>>> we depend on it for a document within this WG otherwise. >>>> >>>> — Justin >>>> >>>> On Oct 6, 2021, at 5:08 PM, Dick Hardt <dick.ha...@gmail.com> wrote: >>>> >>>> I am not supportive of adoption of this document at this time. >>>> >>>> I am supportive of the concepts in the document. Building upon >>>> existing, widely used, proven security mechanisms gives us better security. >>>> >>>> HTTP Sig looks very promising, but it has not been adopted as a draft, >>>> and as far as I know, it is not widely deployed. >>>> >>>> We should wait to do work on extending HTTP Sig for OAuth until it has >>>> stabilized and proven itself in the field. We have more than enough work to >>>> do in the WG now, and having yet-another PoP mechanism is more likely to >>>> confuse the community at this time. >>>> >>>> An argument to adopt the draft would be to ensure HTTP Sig can be used >>>> in OAuth. >>>> Given Justin and Annabelle are also part of the OAuth community, I'm >>>> sure they will be considering how HTTP Sig can apply to OAuth, so the >>>> overlap is serving us already. >>>> >>>> /Dick >>>> >>>> >>>> ᐧ >>>> >>>> On Wed, Oct 6, 2021 at 2:04 PM Aaron Parecki <aa...@parecki.com> wrote: >>>> >>>>> I support adoption of this document. >>>>> >>>>> - Aaron >>>>> >>>>> On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef < >>>>> rifaat.s.i...@gmail.com> wrote: >>>>> >>>>>> All, >>>>>> >>>>>> As a followup on the interim meeting today, this is a *call for >>>>>> adoption *for the *OAuth Proof of Possession Tokens with HTTP >>>>>> Message Signature* draft as a WG document: >>>>>> https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/ >>>>>> >>>>>> Please, provide your feedback on the mailing list by* October 20th*. >>>>>> >>>>>> Regards, >>>>>> Rifaat & Hannes >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > 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
