Re: M2M DID Auth

I read M2M as related to IoT.

What's the current state in aligning DID Auth with SIM cards and FIDO
tokens?

- Adrian

On Wed, May 27, 2020 at 11:42 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)
> 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
>
>
>