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://youtu.be/CYBhLQ0-fwE?t=3003>
[2] https://github.com/httpwg/http-extensions <https://github.com/httpwg/http-extensions>
[3] https://lists.w3.org/Archives/Public/ietf-http-wg/ <https://lists.w3.org/Archives/Public/ietf-http-wg/>
[4] https://github.com/httpwg/http-extensions/blob/master/CONTRIBUTING.md <https://github.com/httpwg/http-extensions/blob/master/CONTRIBUTING.md>


> On May 27, 2020, at 11:41 AM, Leonard Rosenthol <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://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=52897>) 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&amp;data=02%7C01%7Clrosenth%40adobe.com%7Cd7cd581af1a14c351de908d802538b21%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637261905129058820&amp;sdata=S2CT5WCLLlrdDI%2FveXrumSygl%2F2%2Fv5NzJWYv%2F36HDtI%3D&amp;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&amp;data=02%7C01%7Clrosenth%40adobe.com%7Cd7cd581af1a14c351de908d802538b21%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637261905129058820&amp;sdata=MFbBlsO38R6b%2FOjPveby4G9v3XudmeHDpz3QJAmUK%2FI%3D&amp;reserved=0>