RE: Mozilla Formally Objects to DID Core

> Imagine being stuck with MD5 forever, because alternative hash functions were considered a bad idea... or stuck with RSA 512 because  

> adding more public key crypto systems made interoperability harder...

 

IMHO this is a mild example to describe the existing situation with DID core. I don’t think that people are complaining about supporting multiple algorithms and key types. I think the issue is that there are, for example, multiple ways to represent the *same key*, or *the same output of the same hash/signature algorithm*. In my opinion DID core gives too much freedom to implementers. A striking example is the “verification methods registry” (https://www.w3.org/TR/did-spec-registries/#verification-method-properties): why not having only publicKeyJwk? I think that all other verification method properties can be represented as a publicKeyJwk. 

 

From: Orie Steele <orie@transmute.industries> 
Sent: Thursday, September 2, 2021 7:31 PM
To: Jim St.Clair <jim.stclair@lumedic.io>
Cc: Tom Jones <thomasclinganjones@gmail.com>; Markus Sabadello <markus@danubetech.com>; Credentials Community Group <public-credentials@w3.org>
Subject: Re: Mozilla Formally Objects to DID Core

 

Imagine being stuck with MD5 forever, because alternative hash functions were considered a bad idea... or stuck with RSA 512 because adding more public key crypto systems made interoperability harder...

Just because you can use all these registered algorithms:

https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms

does not mean you need to... but it's still helpful to register them...

It enables conversations like this:

https://security.stackexchange.com/questions/100991/why-is-secp521r1-no-longer-supported-in-chrome-others

It's helpful to have a registry for things even if you just use it as a "list of things we don't support"...

Another example:

https://www.zdnet.com/article/apple-declined-to-implement-16-web-apis-in-safari-due-to-privacy-concerns/

Just because some folks want interoperable Web NFC does not mean Apple needs to implement support for it... 

Web standards undermine iOS and Apple's native app based development model (which they charge developers to build on)...

Should Apple also attempt to prevent Web NFC from being a TR?

https://w3c.github.io/web-nfc/ 

Chrome (Google and Microsoft) support it... https://googlechrome.github.io/samples/web-nfc/

Google tends to make use of web standards, sometimes in ways that Apple thinks undermine user privacy... 

Should standards that are free "as in freedom" and "as in beer" be prohibited if they are "paid for" in user data over time?

It's easy to argue that the standard would be better if it were just `did+json` and `JWK`... 

Microsoft advocated for that from the beginning, and ION does not support none-JWK based Key representations...

ION also runs on Bitcoin... but did:web / did:key do not... and they also support JWK...

It's somewhat ironic that Google and Apple think blockchain is somehow incompatible with sustainability...

https://sustainability.google/progress/projects/traceability/

https://www.apple.com/supplier-responsibility/pdf/Apple-Conflict-Minerals-Report.pdf

> Apple continued to participate in the RMI’s Blockchain working group, helping to standardize data interoperability across
minerals blockchain solutions and to ensure data privacy. Apple believes that minerals blockchain solutions should be
used as a tool to support—but not replace—supply chain due diligence...

Transmute has worked on this use case before...

https://twitter.com/TransmuteNews/status/1412839437986197504

OS

 

On Thu, Sep 2, 2021 at 10:23 AM Jim St.Clair <jim.stclair@lumedic.io <mailto:jim.stclair@lumedic.io> > wrote:

“Flexibility on security is not a feature that I would brag about.”

 

…?

 

The opposite of flexibility is rigidity, which historically makes security “brittle”, so I’m not sure I understand…

 

Best regards,

Jim

_______________ 

 

Jim St.Clair 

Chief Trust Officer 

 <mailto:jim.stclair@lumedic.io> jim.stclair@lumedic.io | 228-273-4893 

Let’s meet to discuss patient identity exchange: https://calendly.com/jim-stclair-1

 

From: Tom Jones <thomasclinganjones@gmail.com <mailto:thomasclinganjones@gmail.com> > 
Sent: Thursday, September 2, 2021 10:19 AM
To: Markus Sabadello <markus@danubetech.com <mailto:markus@danubetech.com> >
Cc: Credentials Community Group <public-credentials@w3.org <mailto:public-credentials@w3.org> >
Subject: Re: Mozilla Formally Objects to DID Core

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

Flexibility on security is not a feature that I would brag about.

 

..tom

 

 

On Thu, Sep 2, 2021 at 12:34 AM Markus Sabadello <markus@danubetech.com <mailto:markus@danubetech.com> > wrote:

I sympathize with Mozilla's comments about centralized methods and proof-of-work methods, and I believe these concerns could be addressed in the DID Rubric and DID Implementation Guide documents, without necessarily requiring changes to DID Core itself.

Mozilla's other comment about lack of interoperability is however hard to unterstand for me.

The whole point of DID methods is to ENABLE interoperability between heterogeneous identifier systems.

Some use cases will only use a single DID method and not be interoperable with others.
Some DID methods will become very popular and be widely interoperable across many different systems.
Some DID methods may become standardized (e.g. did:key, did:web) and therefore "effectively mandatory".
Some use cases will want to support as many DID methods as possible, even less popular ones.

This flexibility is a feature, not a bug.

Markus

On 02.09.21 04:11, Orie Steele wrote:

https://lists.w3.org/Archives/Public/public-new-work/2021Sep/0000.html

The objection mentions comments from Google and Microsoft, but does not link directly to them.

Does anyone have a direct link to the comments from Google and Microsoft?

OS

 

-- 

ORIE STEELE 

Chief Technical Officer

www.transmute.industries <http://www.transmute.industries> 

 




 

-- 

ORIE STEELE

Chief Technical Officer

www.transmute.industries

 

 <https://www.transmute.industries/>