Re: Mozilla Formally Objects to DID Core

It would have been really easy to only support `publicKeyJwk` if we had
only JSON representations...

Sadly, we have an Abstract Data Model and a registry for representations
with `did+json` and `did+ld+json` being the most popular... and some folks
objecting to JWK on the grounds that it's a footgun since it defines a way
to represent a private key... "d".... (and ignoring that
`privateKeyMulibase` is already a thing...)

This has been discussed many times by the WG, and I have generally agreed
with the position that Mike Jones from Microsoft and other JWK supporters
have held.... I think everyone should use JWK when representing keys in
JSON...

Long story short, if you are a conservative developer you can in fact use
`did+json` that is the same as `did+ld+json` and also uses JWK...

If you want to experiment with non standard key formats you can also do
that... in a way that allows for interoperability... with or without JSON
or JSON-LD...

This behavior in DID Core was derived from
https://github.com/microsoft/api-guidelines/blob/vNext/Guidelines.md#6-client-guidance

We discussed how to support extensibility and interoperability without
being bound to a single representation... extensively... It would have been
exceedingly easier to just use JSON and call it a day.

I suspect that these "non standard key formats" will eventually be a reason
to use or not use a given did method, because they can harm
interoperability with legacy systems, or require excessive translation on
the client...

OS



On Thu, Sep 2, 2021 at 1:14 PM Nikos Fotiou <fotiou@aueb.gr> wrote:

> > 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/  <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>
> 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
>
> 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>
> *Sent:* Thursday, September 2, 2021 10:19 AM
> *To:* Markus Sabadello <markus@danubetech.com>
> *Cc:* Credentials Community Group <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>
> 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
>
>
>
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
>
>
>
> [image: Image removed by sender.] <https://www.transmute.industries/>
>


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>