Re: Mozilla Formally Objects to DID Core

The only reason the environmental sustainability argument is even a thing
is because if you divide a steadily increasing amount of energy usage by 5
transactions per second it appears like a whole lot of waste.

Has anybody thought about raising the bitcoin block size??? /s

On Thu, Sep 2, 2021 at 11:57 AM Karyl Fowler <karyl@transmute.industries>
wrote:

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