Re: M2M DID Auth

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://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches

Received on Wednesday, 27 May 2020 15:33:35 UTC