IE, if the success of HTTP Signing is tied to the OAuth WG adopting the draft, 
then Mike's arguments about the WG already doing this work is valid.

It's not the success of HTTP Message Signatures that concerns me here; that 
draft will reach RFC regardless of what the OAuth WG does. But I and others 
would like to use Message Signatures with OAuth 2.0, and would like to have 
some confidence that there will be a standard, interoperable way to do that.

There are other, non-OAuth 2.0 use cases for HTTP Message Signatures. I don't 
see the rationale behind waiting for implementations for completely unrelated 
use cases, or by parties that aren't using OAuth 2.0 for authorization. How are 
they relevant?

—
Annabelle Backman (she/her)
[email protected]<mailto:[email protected]>




On Oct 8, 2021, at 1:33 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.


On Fri, Oct 8, 2021 at 12:39 PM Richard Backman, Annabelle 
<[email protected]<mailto:[email protected]>> wrote:

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.

If the main use case for HTTP Signing is the OAuth WG, then effectively the 
OAuth WG is developing HTTP Signing and it is not really a general purpose 
standard.

IE, if the success of HTTP Signing is tied to the OAuth WG adopting the draft, 
then Mike's arguments about the WG already doing this work is valid.



[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=052c9f85-ef8e-44d3-aca8-40ffb9bce5ef]ᐧ

_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to