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

Thanks DW!

> I believe you can catch this via javascript, but you may still get a
browser-supplied error prompt. I haven't tried in a while.

Oooh, excellent, I'll look into that!

> 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. A successful launch of
Europe's wallet initiative may eventually help apply some pressure here.
 > The platform ultimately controls invocation of URLs, be it the browser
or the OS underneath.

Yeah, I agree with you. At the moment, OIDC (or SIOP v2) for individual
consumer usage is limited (kneecapped?) by the whims of the browser and OS
vendors. But there's always hope! (Although, I was sad to see that FedCM,
an attempt by the browsers to address some OIDC/OAuth2 shortcomings in the
UI, still suffers from the same centralizing forces that
non-browser-mediated OIDC has, namely -- individual website-controlled
choice of wallets and identity providers. As opposed to having it be the
user's choice, which is much more preferable.)

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

Agreed, yeah. Do you know if there are any such efforts underway, aside
from CHAPI's mediator?




On Fri, Mar 18, 2022 at 4:46 PM David Waite <dwaite@pingidentity.com> wrote:

> On Fri, Mar 18, 2022 at 12:21 PM Dmitri Zagidulin <dzagidulin@gmail.com>
> wrote:
>
>> > In your opinion, does SIOP help with the NASCAR problem?
>>
>> So, I can definitely speak to this -- No, SIOP does not solve the NASCAR
>> problem, unfortunately. And this has to do with the limitation OS vendors
>> enforce, both on mobile devices and on the desktop. There are two problems
>> with the current `openid://` / custom protocol handler approach.
>>
>> 1. Terrible initial UX. Meaning, if a typical user clicks on an openid://
>> URL on the desktop or on mobile, and they don't have an app installed that
>> handles it, NOTHING HAPPENS. Literally nothing happens. There's no smooth
>> guiding to a marketplace to install a handler, or anything like that. But
>> this is a minor inconvenience, compared to the next one.
>>
>
> I believe you can catch this via javascript, but you may still get a
> browser-supplied error prompt. I haven't tried in a while.
>
>
>> 2. If more than one app is registered as a handler for openid://, and a
>> user clicks on the link, the behavior is *undefined* (at least on IOS).
>> And this is a very well understood problem in the SIOP community -- if
>> you look at the SIOP v2 spec,
>> https://openid.net/specs/openid-connect-self-issued-v2-1_0-03.html#section-7.5.1
>> :
>> "Usage of custom schemas [like openid://] as a way to invoke a
>> Self-Issued OP may lead to phishing attacks and undefined behavior. ... Any
>> malicious app can register the custom schema already used by another app,
>> imitate the user interface and impersonate a good app. When more than one
>> Self-issued OP with the same custom schema has been installed on one
>> device, the behavior of Self-Issued OP is undefined."
>>
>> This is a huge problem, that the community is still strugglign to solve.
>>
>
> 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. A successful launch of
> Europe's wallet initiative may eventually help apply some pressure here.
>
> The platform ultimately controls invocation of URLs, be it the browser or
> the OS underneath. Applications themselves are typically sandboxed from
> introspection of other installed applications as such would be a big
> privacy risk as well as making a whole range of security exploits easier to
> perform.
>
> If a platform DID have first class support, it would solve other issues,
> such as how to more tightly filter requests to a wallet which indicates it
> has the technical capacity to answer it, or even to wallets that hold
> credentials which would meet the stated requirements.
>
> 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. So for example, if a group of issuers, verifiers and wallets all
> wanted to provide merchant age verification they might define the exact
> credential type and format and other specificities and then create an app
> link that all verifiers would be to initiate an installed wallet. If no
> wallet is installed, the app link itself is a descriptive page explaining
> what needs to be done.
>
> If _multiple_ wallets are installed, this is back in the realm of
> platform-specific behavior - although they at least have defined that
> behavior. The trust's list of supporting wallets may be treated as a
> prioritized list, it may provide a user configuration option deep in
> settings, or might give an OS prompt for desired option (including
> potentially launching via an installed browser).
>
> -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.*