Re: Mozilla Formally Objects to DID Core

Chiming in w a less technical view; I share the perspective that all 4
objection points are not sufficiently compelling.

Building on Orie's reply, some of the objecting companies are not just
using the very technologies they're objecting to (see their use of
Minespider for conflict mineral tracking which appears to use an ETH-based
blockchain; <https://www.minespider.com/blockchain-technology> ETH is still
POW with transition plans to POS in motion). IMHO, they are using the
environmental argument in a way that hand-waves over the nuance of this
issue.

*Food for thought:* due to the highly competitive nature of POW mining,
operations are increasingly selecting sites that are in areas where there
is excess stranded energy in order to access the cheapest electricity
prices. Wind and solar are the cheapest forms of energy generation, but
suffer from intermittency which can cause stability issues for the grid.
Bitcoin mining is a "flexible load" and can help to stabilize grids with
large amounts of renewables - enabling more renewable energy
development. Square’s
recent whitepaper outlines these dynamics
<https://assets.ctfassets.net/2d5q1td6cyxq/5mRjc9X5LTXFFihIlTt7QK/e7bcba47217b60423a01a357e036105e/BCEI_White_Paper.pdf>.
Bitcoin miners are doing this today - like my friends at HODL Ranch
<https://www.hodlranch.io/> here in Texas (where we are desperately aware
of the need for grid stabilization).

Core to Transmute's founding mission is the belief that DIDs coupled with
VCs are a better way for organizations to prove/showcase their positive
societal contributions - whether that's proving sustainable/low
environmental impact processing of raw materials or proving ethical labor
practices. Likewise, pragmatic application of DIDs and VCs can help us hold
companies and governments accountable to honest, truthful performance in
these arenas. Now, you certainly don't need a public blockchain - or a
blockchain at all - in order to use DIDs or VCs, and our team has been a
leading advocate for ensuring these technologies are interoperable
regardless of ledger use. But when you *do* want to use a blockchain, the
environmental impact debate requires recognition of nuance and is certainly
not a sufficient argument against the progress of DIDs.

Best,
-- 


*KARYL FOWLER*Chief Executive Officer
www.transmute.industries

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

ᐧ

On Thu, Sep 2, 2021 at 1:38 PM Orie Steele <orie@transmute.industries>
wrote:

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