Re: Open Wallet Foundation

I think we need to look to Elizabeth M. Renieris
<https://www.amazon.com/s/ref=dp_byline_sr_book_1?ie=UTF8&field-author=Elizabeth+M.+Renieris&text=Elizabeth+M.+Renieris&sort=relevancerank&search-alias=books>
-
see below For an answer.  We have become fixated on tracking the user with
data about the user. That is what Apple pitches and what the EU seeks to
control.  It is never going to work. The protocols, apis and whatnot will
not save us. we need to control the behavior of the devices that
ostensibly work for us. Anders is correct to point out the critical point,
transitioning from the web to the wallet, but he is wrong about the fix. A
wallet can grab an endpoint, but that endpoint can be taken over by another
"wallet" from another source, so the endpoint cannot serve two wallets, nor
can it be protected from hijacking. Until this point is secured, there is
no way available today to protect user secrets from being hijacked. Unless,
of course, we trust the phone provider to do it for us by using their
wallet.

Beyond Data: Reclaiming Human Rights at the Dawn of the Metaverse
https://www.amazon.com/Beyond-Data-Reclaiming-Rights-Metaverse/dp/0262047829

Be the change you want to see in the world ..tom


On Sat, Sep 17, 2022 at 6:58 AM Orie Steele <orie@transmute.industries>
wrote:

> Unfortunately you can't use WebAuthN to get generic signatures needed to
> treat a device as a wallet.
>
> 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> wrote:
>
>>
>> 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
>>
>> 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.
>>
>>