W3C home > Mailing lists > Public > public-credentials@w3.org > September 2021

Re: Mozilla Formally Objects to DID Core

From: Orie Steele <orie@transmute.industries>
Date: Thu, 2 Sep 2021 11:30:39 -0500
Message-ID: <CAN8C-_+X=tgdW72JPiZXfsPoCcwNhsrhgk+W56qdiY-r=dHgxg@mail.gmail.com>
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>
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
>
>
>
> <https://www.transmute.industries>
>
>

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

<https://www.transmute.industries>

image001.png
(image/png attachment: image001.png)

Received on Thursday, 2 September 2021 16:31:10 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 September 2021 16:31:12 UTC