Re: M2M DID Auth

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) 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> 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

    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

Received on Wednesday, 27 May 2020 15:42:03 UTC