- From: Tobias Looker <tobias.looker@mattr.global>
- Date: Mon, 21 Mar 2022 00:56:27 +0000
- To: Manu Sporny <msporny@digitalbazaar.com>, "public-credentials@w3.org" <public-credentials@w3.org>
- Message-ID: <SY4P282MB1274066565B483BE5222CF279D169@SY4P282MB1274.AUSP282.PROD.OUTLOOK.COM>
> This does not solve the problem of invoking a digital wallet on the same device. For example, you're on your mobile phone browsing a website and want to pick up a credential. QR Codes do not help you in that situation, which is a very common one. > So, this one is a non-solution to the problem that CHAPI solves (same-device invocation of a web or native wallet on the same device). There was never any assertion made that this mechanism was suitable for "same-device", hence why the description starts with the words "cross-device". The list supplied was to describe the different ways a request can be passed to a wallet using SIOP v2. What it does highlight is that SIOP v2 supports more mediums to hand a request to a wallet than the CHAPI model which shows in my mind why the protocol (OIDC/SIOP) should be separate from the mediation layer that gets added on top when you are in an environment like a browser that requires wallet chooser style mediation. Are we fundamentally comparing the wrongs things here? Should we instead be comparing VPR + VC API to the OIDC protocols? > The issue isn't cross-device... it's same device wallet invocation (which is a very common use case). 100% agree that the NASCAR problem is mostly an issue for same-device style interactions, but are you saying cross-device use-cases have no value and we shouldn't design a protocol that works for that too? Thanks, [Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0> Tobias Looker MATTR CTO +64 (0) 27 378 0461 tobias.looker@mattr.global<mailto:tobias.looker@mattr.global> [Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0> [Mattr on LinkedIn]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D&reserved=0> [Mattr on Twitter]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D&reserved=0> [Mattr on Github]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D&reserved=0> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. ________________________________ From: Manu Sporny <msporny@digitalbazaar.com> Sent: 21 March 2022 10:05 To: public-credentials@w3.org <public-credentials@w3.org> Subject: Re: Centralization dangers of applying OpenID Connect to wallets protocols (was: Re: 2022-2026 Verifiable Data Standards Roadmap [DRAFT]) EXTERNAL EMAIL: This email originated outside of our organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. On 3/19/22 6:52 PM, Tobias Looker wrote: > 1. Local Invocation via URL schemes or platform-registered HTTPS URL (e.g. > universal links, app links) As Dmitri elaborated earlier, this solution doesn't work for web-based wallets and it only (partially) works for native app-based wallets. If there isn't a URL scheme handler registered, the UX is awful (nothing happens and you can't always detect that nothing happened). You are also forcing the individual to install a native app instead of allowing them to pick among web-based and native-based apps. To contrast, CHAPI's approach works across the vast majority of browsers and platforms, both for web-based wallets (via postMessage) and for native wallets (via Web Share). That's not to say that CHAPI is perfect on every platform, but it's certainly far more capable than native URL Scheme handlers. > 2. Cross-device Invocation via QR code holding above initiation URL This does not solve the problem of invoking a digital wallet on the same device. For example, you're on your mobile phone browsing a website and want to pick up a credential. QR Codes do not help you in that situation, which is a very common one. So, this one is a non-solution to the problem that CHAPI solves (same-device invocation of a web or native wallet on the same device). > 3. Cross-device invocation via wallet QR code reader Again, different problem, and easy to address w/ a QR Code reader in a digital wallet. The presumption here is that you're starting at your digital wallet -- presuming that digital wallets are going to be the centre of the ecosystem and people's desired experiences is problematic. The issue isn't cross-device... it's same device wallet invocation (which is a very common use case). -- 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/
Received on Monday, 21 March 2022 00:56:46 UTC