- From: David Waite <dwaite@pingidentity.com>
- Date: Mon, 21 Mar 2022 17:06:44 -0600
- To: Anders Rundgren <anders.rundgren.net@gmail.com>
- Cc: Tobias Looker <tobias.looker@mattr.global>, "dzagidulin@gmail.com" <dzagidulin@gmail.com>, Manu Sporny <msporny@digitalbazaar.com>, "public-credentials@w3.org" <public-credentials@w3.org>
- Message-ID: <CA+3kW=ajdsu6q0R21ocJF+1NFJguko8vY1EMM7Yqtt14Kb2v2A@mail.gmail.com>
On Sun, Mar 20, 2022 at 2:32 AM Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > On 2022-03-19 23:52, Tobias Looker wrote: > > > Can you say more about those multiple ways? If I'm understanding > correctly, there is just one mechanism that SIOP supports, and that is > through a custom url protocol link. Is that not the case? > > > > > > I guess it depends on what you constitute as being different in this > context? What I meant here was the options that DW listed. > > > > > > 1. Local Invocation via URL schemes or platform-registered HTTPS URL > (e.g. universal links, app links) > > Or by misusing PaymentRequest which is a pretty good replacement for the > eternally missing Web2App API: > https://cyberphone.github.io/doc/web/calling-apps-from-the-web.pdf This seems to use URL schemes or claimed URLs itself, without any special platform level support (e.g. listing applications which advertise a certain characteristic for the user to choose). So it should have the same trade-offs today, with a different API on front. > > > 2. Cross-device Invocation via QR code holding above initiation URL > > I'm not sure what that means. > SIOP requests are encoded within a URL with either a custom scheme or based on a claimed URL. Multiple SIOPs (aka wallets) can advertise with the platform support for the same custom scheme or that they claim the same URL. If you embed a SIOP request (URL) in a QR code, it is scannable by a third party/system QR code reader on the other device, and the URL will be used to launch an application (or for a claimed HTTPS URL, potentially the browser). If there are multiple applications which claim the same scheme or custom URL scheme installed on the user device, we fall back to platform behavior - that may be a prompt, a user configuration setting, a prioritized list, or even some behavior like 'most recently launched'. > > > > 3. Cross-device invocation via wallet QR code reader > > In this case I guess that most existing wallets invoke the app directly, > eliminating any dependencies on Web standards. > Yes, you basically ignore the custom URL scheme or claimed URL prefix and just take the request out of the URL parameters. This skips platform behavior for interpreting URLs and picking a registered application. > Finally: A proper Web2App API would extend trough paired BLE so that > mobile wallets could register their abilities and thus dealing with the > NASCAR problem in the same way as same-device solutions. In fact, it would > be transparent for invoking Web applications where the wallets are situated. > URL launching across devices is certainly something we've thought about. One common problem here is that the more the process looks like it is being mediated by some party (such as the underlying platform provider), the more people will assume the platform is protecting them from potential malicious behaviors like phishing. -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._
Received on Monday, 21 March 2022 23:08:08 UTC