- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Sat, 17 Sep 2022 17:28:30 +0200
- To: Orie Steele <orie@transmute.industries>
- Cc: W3C Credentials Community Group <public-credentials@w3.org>
On 2022-09-17 15:54, Orie Steele wrote: > Unfortunately you can't use WebAuthN to get generic signatures needed to treat a device as a wallet. Right. However, the (deliberate) limitation is actually in WebAuthN (=the browser), not in FIDO. The only issue at the FIDO level is that signatures have a specific format which is incompatible with JOSE/COSE. This is not a showstopper. The "only" showstopper I'm aware of is that applications using FIDO keys must be granted access by the platform vendor. Anders > > I spoke with some folks in the WG about this a while ago. > > They said it was intentional, to avoid tracking / privacy issues. > > It's unfortunate that they didn't let the users decide this. > > There are cases where I want pairwise unique cryptographic identifiers, and there are cases where I want boring public keys and signatures. > > When a user allows for MetaMask to share Ethereum addresses with a website, their intentions is not to remain uncorrelated, it's to keep building reputation on a set of identifiers they control. > > The WebAuthN model assumes that only a web server can make this choice, not a user in their browser. > > Imagine is WebAuthN allowed you to sign transaction that transfer crypto currency / nfts? > > Imagine if WebAuthN allowed you to issue verifiable credentials or present them with authentication to a server? > > It was not built for these use cases... Its only mission is authenticating users, in a way that protects their privacy but leaves them beholden to a platform for identity, payments and reputation. > > This also means that as much as you might want to treat a platform authenticator such as TouchID or FaceID as hardware wallets (in the crypto currency sense), you can't. > > You can build a hardware authenticated wallet on top of them though... Just need to put extra trust that hsm backed keys are only accessed by users who have been authenticated by these technologies... And of course an insider can always snip snip that trust. > > Regarding OWF, I think it's about time we came together to talk about wallet interoperability, use cases and threats to users... It's young, we can all be a part of shaping it. > > I'm interested in continuing the conversations we've been having regarding the universal wallet interop spec in a wider group, and especially looking at the overlap with tokenized credit cards and other payments methods compared to crypto currencies and verifiable presentations. > > Not your keys, not your identity, privacy, money, reputation, capabilities... Not under your control... Not controlled by you... Delegation can only come after user control is established. > > Only open wallets can deliver on this without creating vendor lock. > > Regards, > > OS > > > > On Fri, Sep 16, 2022, 11:47 PM Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote: > > https://www.linuxfoundation.org/press/linux-foundation-announces-an-intent-to-form-the-openwallet-foundation <https://www.linuxfoundation.org/press/linux-foundation-announces-an-intent-to-form-the-openwallet-foundation> > > The merits of this proposal is yet to be seen but presumably it builds on that the wallet is a part of the native platform. This is IMO also the only solution that can be certified. > > Personally, I would though build a wallet around FIDO. The recent additions to FIDO and its companion standard WebAuthn are simply put unrealistic to copy. > > That using FIDO results in signature schemes that doesn't map directly to JOSE and COSE is a no-issue compared to the rest. I have succeed using raw FIDO signatures for payment authorizations with almost no effort at all: https://github.com/cyberphone/ctap2-sign <https://github.com/cyberphone/ctap2-sign> > > Using FIDO (not WebAuthn) a wallet function would constitute of > Standard FIDO Key + Custom Meta Data + Custom Process > where the Custom Meta Data also holds a handle (credentialId) to the associated FIDO key. > > However, the problem I have been struggling with like forever remains: the proper way of invoking a native wallet from the Web [*]. Another issue which apparently nobody is dealing with, is how to invoke a wallet in the physical world. Although QR codes work, but they are way less useful than Apple Pay with NFC. This topic may be out of scope for the W3C but in the same way as with payments, the market doesn't care :) > > Cheers, > Anders > > > *] Due to the browser tech monopoly, browser innovation is effectively limited to Google and Apple. Well, Microsoft could play another role since they have discontinued their Microsoft Wallet. >
Received on Saturday, 17 September 2022 15:28:44 UTC