Re: Open Wallet Foundation

https://gitlab.grnet.gr/essif-lab/infrastructure/fraunhofer/train_project_summary

https://openid.net/gainpoc/

https://identity.foundation/trust-establishment/


I think there are 2 cases related:

1. Where the wallet controller is not trusted to choose trust framework

2. Where the wallet controller is trusted to choose trust framework

They impact wallet software differently, due to the cost of integrating all
protocols required for a given framework, or multiple frameworks.

Regards,

OS

On Sun, Sep 18, 2022, 3:36 AM David Chadwick <
david.chadwick@crosswordcybersecurity.com> wrote:

> This one of the problems that we can solve with the TRAIN trust
> infrastructure from Fraunhofer, and it is one of our work items in the EU
> funded NGI Atlantic project. The OIDC Federation draft also has a solution
> for this. The OIDF GAIN working group is also working on this problem trans
> federations. All the solutions are based on protocols rather than wallet
> design.
>
> Kind regards
>
> David
> On 17/09/2022 17:18, Tom Jones wrote:
>
> can the receiver of the money be verified - yes Anderes that is the issue.
> We have identified that in the Mobile Driver's license and are trying to
> address in the wg on Privacy Enhancing Mobile Credentials. The wallet must
> be toldou the ID of the verifier and be able to determine if it is
> legitimate.
>
> Be the change you want to see in the world ..tom
>
>
> On Sat, Sep 17, 2022 at 8:39 AM Anders Rundgren <
> anders.rundgren.net@gmail.com> wrote:
>
>> On 2022-09-17 17:26, Tom Jones wrote:
>> > 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.
>>
>> I'm unable to decipher what the problem is and how it possibly could be
>> fixed.
>>
>> For payments the core problem is verifying that the receiver of money is
>> genuine but this appears to be outside of what a wallet can possibly handle.
>>
>> Anders
>>
>> >
>> > Beyond Data: Reclaiming Human Rights at the Dawn of the Metaverse
>> >
>> https://www.amazon.com/Beyond-Data-Reclaiming-Rights-Metaverse/dp/0262047829
>> <
>> 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>
>> <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 <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.
>> >
>>
>>