Re: M2M DID Auth

Thanks for the detailed response, Justin!  I will take this back with me to ETSI and make sure that we align…

I’ll do my best to participate where and when I can…appreciate the links.

Leonard

From: Justin Richer <jricher@mit.edu>
Date: Wednesday, May 27, 2020 at 3:00 PM
To: Leonard Rosenthol <lrosenth@adobe.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>, "public-credentials@w3.org" <public-credentials@w3.org>, Annabelle Richard Backman <richanna@amazon.com>
Subject: Re: M2M DID Auth

Hi Leonard,

The HTTP WG draft is currently undergoing some core changes, to both the syntax and details of the approach. The goal will still be to have a way to consistently normalize and sign HTTP messages, but strict compatibility with cavage-10 (or cavage-12) is not a stated goal. The Cavage drafts are a fantastic starting point to work from, though, and we are able to stand on the many years of experience that the community brings across the various individual implementations and drafts. It’s our goal with the HTTP spec to have something that can work across many different use cases, and potentially even be built into libraries and platforms so developers can simply call something like fetch(url).sign(key).then(…), for instance. Having an RFC-track document in the official HTTP WG is probably the best way to move toward that eventual reality. I can’t predict the timing of it, as standards groups are notoriously unpredictable, especially with timing. :)

It’s not the goal of the HTTP WG to change things simply for the sake of change, but neither is it the goal to put a stamp on previous practices and publish as-is. There’s always a balancing act between what’s been done and what’s possible, and I think the direction we are going with draft-http-message-signatures under Annabelle’s leadership is a very good one. I’m excited to see how we can refine and adapt this spec into something that’s generally applicable across a wide swath of the internet, even beyond the use cases that any of the input drafts have brought to the table.

Yaskin’s packaging draft solves a fundamentally different problem, but it needs a signature over the packaged contents returned. It’s possible, and even likely, that we’ll be able to align the two efforts. We are both aware of each other’s work, and we’ll be touching base going forward. This is another huge benefit of doing the work within an official IETF group, we can now more easily and officially coordinate. One of the reasons I got involved with the HTTP Signatures work was my realization that there were a LOT of different, incompatible competing proposals out there[1] and I saw an opportunity to pull everything together. The Cavage individual draft series is one of those inputs, and it’s provided the strongest base for us to start working from. We’ll be taking inputs from other documents, such as the OAuth HTTP Signing draft that I wrote many years ago as well as newer concepts like HTTP Structured Headers in our definitions.

If you’re interested in seeing this work go forward, I invite you to join us! We will be doing the work via the HTTP WG’s GitHub repository on HTTP Extensions[2], and major decisions will be discussed and confirmed on the HTTP WG’s mailing list[3]. All of these are covered by the IETF Note Well IPR policies, which means among other things that you don’t have to formally join the group to participate as long as you abide by the contribution requirements [4].

 — Justin

[1] https://youtu.be/CYBhLQ0-fwE?t=3003<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.be%2FCYBhLQ0-fwE%3Ft%3D3003&data=02%7C01%7Clrosenth%40adobe.com%7C859a176a9a0e4f624a1608d8027045fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637262028526747349&sdata=tyZRaj7nk1GfukT4gFgjoGBV9W3Vgfc9XEU%2F5ylpWb8%3D&reserved=0>
[2] https://github.com/httpwg/http-extensions<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhttpwg%2Fhttp-extensions&data=02%7C01%7Clrosenth%40adobe.com%7C859a176a9a0e4f624a1608d8027045fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637262028526747349&sdata=%2FNERlr2BRXP6kYI7f4Ls3s%2BnnjSszsQUK45jhJp6TJU%3D&reserved=0>
[3] https://lists.w3.org/Archives/Public/ietf-http-wg/<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fietf-http-wg%2F&data=02%7C01%7Clrosenth%40adobe.com%7C859a176a9a0e4f624a1608d8027045fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637262028526757336&sdata=fSaPWwNFH434Z26ownVUdvC0vb7%2B4uLzCPvcGLDogIA%3D&reserved=0>
[4] https://github.com/httpwg/http-extensions/blob/master/CONTRIBUTING.md<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhttpwg%2Fhttp-extensions%2Fblob%2Fmaster%2FCONTRIBUTING.md&data=02%7C01%7Clrosenth%40adobe.com%7C859a176a9a0e4f624a1608d8027045fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637262028526757336&sdata=dDXuEGsr5C%2FKyl6DLPxdndigRAIspa%2F6Xha79bmAY%2Bg%3D&reserved=0>



On May 27, 2020, at 11:41 AM, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:

Thanks - that's what I need to hear/know...

Working on the JAdES standard (https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=52897<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fportal.etsi.org%2Fwebapp%2FWorkProgram%2FReport_WorkItem.asp%3FWKI_ID%3D52897&data=02%7C01%7Clrosenth%40adobe.com%7C859a176a9a0e4f624a1608d8027045fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637262028526767331&sdata=Iux5NWbGynf38HO5q6KVGWIR2tl6yWwe3pnKK1Cypqw%3D&reserved=0>) with ETSI and one of their key use cases is for signing messages.  Trying to find the balance between implementations already in use and a standard/spec that we can refer to normatively.   Annabelle and Justin - anything you can add that will help me move things forward would be great!

Also, do any of you have an understanding how that document on signing http messages is designed to relate to Jeff Yaskin's packaging of HTTP message proposals?

Thanks,
Leonard

On 5/27/20, 11:35 AM, "Manu Sporny" <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:

   On 5/27/20 11:01 AM, Leonard Rosenthol wrote:

Manu - which version of the "Signing HTTP messages" spec are you
working with?

   IIRC, we are using cavage-10 ...


In a discussion at ETSI this week, it came to my attention that many
people in the banking sector (at least in the EU) are using active
implementations based on the draft-cavage-10 version instead of the
current cavage-12 or httpbis-00.  And it's my understanding that that
recent update (httpbis-00) is *not* compatible with the cavage-10.
Is that correct?   Can you comment about why the committee moved away
from compatibility given known implementations?

   In general, everyone is operating in good faith to build the
   biggest/safest tent possible, so we should start there.

   When a specification transitions into an official WG, the WG often says
   things like "We need to have complete control in our ability to ensure
   that the specification meets the requirements of an international
   standard". In order to do this, WGs often make breaking changes,
   sometimes to the dismay of implementers that have deployed the
   technologies. In some of those cases, the implementers decide to never
   upgrade to the latest version (because the version they deployed works
   for them, is stable, and the improvements made by the WG don't impact
   them). In many cases, implementers do upgrade.

   The "Signing HTTP Messages" Internet Draft is ancient (as far as
   specifications go... where the initial implementations date back to 2011
   and the spec dates back to 2013). So, there has been a lot of time for
   implementations to sneak out into production. This happened largely
   because I didn't have the spare time to move the spec forward at IETF
   (and there were companies that noted that they'd block any attempt to do
   so... because the Internet didn't need yet another digital signature
   standard).

   I've cc'd Annabelle, who is the Editor appointed by the IETF HTTP WG for
   the Signing HTTP Messages specification, and she can speak to the
   incompatibilities and where she sees those going in the upcoming
   revisions to the specification. I'd like to point out that Annabelle has
   done an excellent job of improving the specification during her time as
   Editor. I expect things in the specification to improve over the long
   term. I'll also note that Justin, who is involved in this community (and
   others) is helping as well, and will be able to channel at least some
   concerns from those viewpoints as well.

   Similarly, I'm there merely to channel the current set of
   implementations toward the specification. Many of them aren't paying too
   much attention now because what's implemented is working for them
   (Mastodon community, ETSI, etc.). I do have concerns about some other
   actors at IETF attempting to ram JOSE concepts into the spec where they
   don't fit, or pulling in legacy security thinking into the
   specification, but that's the risk we take when we want the document to
   become an official IETF RFC - we have to open everything up to debate
   among a larger community.

   Leonard, I know this isn't a specific answer to your question, but given
   your background, my expectation is that you understand this as standard
   practice. If changes to the spec negatively impact implementations,
   people will say stuff about it. If the Editor and WG doen't do enough to
   address those concerns, the specification becomes a work of fiction,
   with the implementers doing what they want to do anyway. It's a delicate
   balance, but given the people involved, I trust that things will work
   out in the end... after a number of debates filled with flying fur and dust.

   -- manu

   --
   Manu Sporny - https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&amp;data=02%7C01%7Clrosenth%40adobe.com%7Cd7cd581af1a14c351de908d802538b21%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637261905129058820&amp;sdata=S2CT5WCLLlrdDI%2FveXrumSygl%2F2%2Fv5NzJWYv%2F36HDtI%3D&amp;reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&data=02%7C01%7Clrosenth%40adobe.com%7C859a176a9a0e4f624a1608d8027045fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637262028526767331&sdata=z4JcknLtd4m8Z7OyH6ART%2Bs0EU%2B6LDNrUdmRRVMi3hk%3D&reserved=0>
   Founder/CEO - Digital Bazaar, Inc.
   blog: Veres One Decentralized Identifier Blockchain Launches
   https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftinyurl.com%2Fveres-one-launches&amp;data=02%7C01%7Clrosenth%40adobe.com%7Cd7cd581af1a14c351de908d802538b21%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637261905129058820&amp;sdata=MFbBlsO38R6b%2FOjPveby4G9v3XudmeHDpz3QJAmUK%2FI%3D&amp;reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftinyurl.com%2Fveres-one-launches&data=02%7C01%7Clrosenth%40adobe.com%7C859a176a9a0e4f624a1608d8027045fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637262028526777325&sdata=upJYE4hl0Htq48huXlqO0UPXpj4f3Mva2JYX%2FKe4L2Q%3D&reserved=0>