W3C home > Mailing lists > Public > public-credentials@w3.org > March 2022

Re: Centralization dangers of applying OpenID Connect to wallets protocols (was: Re: 2022-2026 Verifiable Data Standards Roadmap [DRAFT])

From: Orie Steele <orie@transmute.industries>
Date: Tue, 22 Mar 2022 13:51:43 -0500
Message-ID: <CAN8C-_LBEhS8oRQ4pt6WnTTbnGm=O9WL9XWh1OAkCjEua=n5RQ@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
I'm not trolling, you can't just focus on building apps and app
layer protocols... you need to focus on the full software supply chain to
prevent abuse.

See this article from 2012 -
https://www.zdnet.com/article/do-we-need-a-smartphone-bill-of-rights/

My point was that as a developer, I like being able to install the OS I
choose, sometimes choosing to build that OS from source before installing
it.

I consider hardware, os and app layers all areas where healthy competition
is needed to protect consumers.

Attackers and dominant market players will always look for a choke point...
A choke point looks like 1 or 2 companies controlling an entire layer of
the stack and leveraging first party data from their control of the
platforms in that layer, competing in that layer becomes difficult.

For example, consider "app / os layer" security for ssh vs hardware
security for ssh: https://github.com/maxgoedjen/secretive

Is a secure enclave a "hardware wallet" ? (yes in the world of crypto
currencies)

What happens when hardware wallets become required but only "approved
operating systems" can access them?

How do protocols know they are talking to a "secure enclave" vs a virtual
machine?

I don't think we can just dismiss the challenges around hardware /
operating systems  / web browsers and web apps vs native apps.

> "Stop trying to create an open wallet ecosystem and just accept vendor
lock in."

No, but ... we need to acknowledge where vendor lock in exists before we
can address it seriously.

Vendor lock in applies to all layers and it gets worse the closer to the
hardware you get... it also gets more expensive to compete the closer to
the hardware you get... and if security comes from trusted hardware, that
should concern us.

Implementing more web apis that offer access to devices is critical to
enabling healthy competition at the layers beyond the hardware and the
OS... That Mozilla and Apple are so strongly opposed to this is creating a
market pressure that is driving secure use cases away from the web
platform... If that's because it's impossible to secure the web platform if
it has good general purpose device APIs, that's understandable, but if
instead that's happening to drive more users into native apps or because
browser vendors can't afford to implement secure device apis based on open
standards, that's a problem... and not one solved by building more apps or
app layer protocols.

If we can get OIDC to penetrate to these lower layers, it's worth it IMO,
armies travel both directions on roads.

OS





On Tue, Mar 22, 2022 at 12:56 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 3/22/22 12:31 PM, Orie Steele wrote:
> > The OS is the original wallet... If you don't control the OS, and the
> > hardware... your identity is just rented to you.
>
> I'm not sure of what point you're trying to make, Orie, but my read on your
> response is one of trolling an otherwise fruitful thread of discussion.
>
> Your point seems to be: "Stop trying to create an open wallet ecosystem and
> just accept vendor lock in." ... when there are already examples of
> competitive wallet ecosystems built on the very platforms you say it can't
> be
> done on:
>
> https://www.cryptowisser.com/wallets/
>
> What strategy are you suggesting to the group?
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>
>

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

<https://www.transmute.industries>
Received on Tuesday, 22 March 2022 18:52:08 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:29 UTC