[Openid-specs-ab] SIOPv2 Use Case question

[David Waite]

> On Apr 19, 2022, at 7:32 AM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
> 
> One option we are considering is to have a trusted list with URLs/claimed URLs specific to individual wallets. Two reasons: 
> 1) a single URL per trust framework does not work for web wallets (well, except the case were non is installed yet on the user’s device)

I’ll admit to be far more focused on the zero wallets installed and single wallet installed cases, over the idea that you would want to select between multiple viable native and PWA wallets.

There is some ongoing effort to specify this behavior in a PWA manifest ( https://github.com/w3ctag/design-reviews/issues/695 ) and Google will let a PWA register intents on Android, but I haven’t had any practical experience on how this intent registration differs from AppLinks.

> 2) It might be simpler to curate white lists of wallets instead of having every wallet registering for a couple of trust framework specific Urls.

It might. It depends on whether you have a few good wallets, or say one per platform per legal jurisdiction plus an assortment of third party vendors.

In any case, I would imagine the trust framework themselves would have guidance on single invocation vs invocation via nascar/list.

> 3) One will anyway need such lists in order to really decide whether a certain wallet conformance to a certain trust framework. As far as I have understood, in case of Android (deep links) there is no way to enforce (from a trust framework operator perspective) that only compliant wallets register for the respective URL. Any wallet can at least register for the deep link. 

If a trust framework has gone so far as to explicitly not want particular wallets to be used, they will likely also not allow that wallet to be issued credentials.

Unfortunately while Android added this most likely from a user-empowerment perspective, they likely have put themselves in the point of getting sucked into future disputes between parties.

> 4) On iOS, the OS enforces a certain order among the registered apps. That doesn’t really fit with a market place (which for example the eIDAS trust framework is). 

Indeed, this is an issue. If the trust framework believes that the user will purposely install multiple wallets, they’ll need to push user choice up front in the web context (e.g. nascar or picker list).

-DW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220419/e56d1c6e/attachment.html>