I agree that Token Binding is not an experience we want to repeat, and I understand having a "once bitten, twice shy" reaction to this. However, the circumstances that led to Token Binding's failure do not apply to Message Signatures. Token Binding required changes in the user agent, meaning that an AS/RS/client could only use Token Binding if an unrelated party – the browser vendor – had already deployed support for it. This is not the case for Message Signatures. Any service can use Message Signatures, as long as they can convince their clients to use it. (And vice versa)
Regarding adoption, bear in mind that Message Signatures is not a complete security solution (by design) – it is a building block, intended to be used within some higher level authorization protocol. (e.g., OAuth 2.0) I'd expect that most parties that use OAuth 2.0 today and are interested in Message Signatures will hold off on implementing the latter until the WG tells them how to use it with their existing OAuth 2.0 deployment. Blocking WG development of an OAuth 2.0 profile of Message Signatures behind widespread deployment of Message Signatures risks creating a deadlock where the WG is waiting for implementations from would-be implementers who are waiting for guidance from the WG. Worse, rejecting the draft is likely to further discourage these parties from implementing Message Signatures, as it suggests the WG is not interested in standardizing its usage with OAuth 2.0. As I mentioned, I think Justin and Annabelle (and anyone else interested) can influence HTTP Sig to cover OAuth use cases. While I appreciate your faith in our abilities, it is difficult to advocate for requirements that have not been defined, and harder still to when advocating on behalf of a Working Group that has said it is not interested in Message Signatures. — Annabelle Backman (she/her) [email protected]<mailto:[email protected]> On Oct 6, 2021, at 2:55 PM, Dick Hardt <[email protected]<mailto:[email protected]>> 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. 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 [https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=220e8879-1cf9-481e-804c-a9ca9622d19e]ᐧ On Wed, Oct 6, 2021 at 2:48 PM Aaron Parecki <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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. [https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=43ada4a0-1251-44ee-b32c-f82f530a9e53]ᐧ On Wed, Oct 6, 2021 at 2:20 PM Justin Richer <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 [https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=50ab0782-c889-43c8-9cb2-819eda9391bc]ᐧ On Wed, Oct 6, 2021 at 2:04 PM Aaron Parecki <[email protected]<mailto:[email protected]>> wrote: I support adoption of this document. - Aaron On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
