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

On Sat, Mar 19, 2022 at 4:09 PM Dmitri Zagidulin <dzagidulin@gmail.com>
wrote:

> Earlier, responding to my lament that openid:// custom protocol handling
> is not very well supported by OS vendors, DW said: "To be honest, I don't
> see this being solved without a first-class interface for javascript and
> native apps, similar to what WebAuthn has created for pure authentication
> credentials."
> And later in that same reply, "Today, the best pitch we have (other than
> scanning a QR code with your chosen wallet on another device) is app links
> maintained by a trust framework.".
>

I'd agree with that.

My focus has been on enabling a system that works well enough when the
majority of people will not have software which can handle such a system.
They will not have installed an app or web extension to provide CHAPI. They
will not have a wallet installed which supports DIDComm.

If the service end user gets a javascript invocation error (or worse,
nothing), or gets a QR code that just copies a bunch of JSON to their
clipboard, they will not know how to use the system.

If end users who have not been educated in and invested into wallets don't
get a good experience out of the box, services are not going to become
verifiers.

The SIOP solution today to avoid NASCARing is that multiple wallets are
invocable with the same custom URL scheme or the same app link, in addition
to being able to understand such a request if embedded within a scanned QR
code.

My promotion of such a scheme is due to thinking it gets us farther along
adoption. That provides leverage for issuers, verifiers, wallets and
holders to together push for a more comprehensive solution for platforms.

Which, as far as I know, we don't really have one of those (an app link
> mediated by a trust framework). (Other than CHAPI's mediator.)


The problem is that mediation between the sandboxes is a platform function,
and visibility as well as state persistence will be increasingly locked
down.

Depending on the browser, a pure web CHAPI may involve juggling tabs and
windows for native wallets, it may involve the user accepting multiple
prompts around sharing data that may result in tracking, and may see its
registrations deleted due to periods of non-use.

That's not to say that CHAPI is a poor implementation or an inferior
approach amongst the options; it obviously has trade-offs along with
everything else.

Instead, I am pointing out that modern consumer platforms (operating
systems _and_ browsers) are built and continue to evolve to further sandbox
and isolate processes by company or web domain, as well as limit state
sharing and IPC.

So, I would still maintain, than until this problem is solved, SIOP is
> basically unusable, for getting VCs/VPs into wallets.


I would argue it is one of the better options for actual adoption.

-DW

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._