Difference between revisions of "Wallet"

Revision as of 12:20, 10 November 2024

Full Title or Meme

The Wallet is a word with a common well-known meaning in real-life repurposed for use in Identity Management to an active digital app that can securely hold holder (or Subject) identifier secrets.

Some Wallet apps are designed to support any digital Entity, but this wiki focuses on wallet apps designed for human holders.

Taxonomy

There is some confusion of the meaning of digital wallet so here is a list of the words used in the page: (These are worked out in some detail in the solutions section below.)

Secure Wallet (for our purposes) holds user private keys and similar secrets in non-exportable storage.
Cloud Wallet holds secrets on a web server. Those secrets may be "owned" by natural or legal entities.
Hybrid Wallets will be a combination of an app that has components in the cloud and on a device in control of a holder.
A native wallet is an app that is (nearly) completely contained on a device owned by a user.
A web wallet (for our purposes) is a JavaScript (or similar) app downloaded by a web server into a browser execution environment.

Context and History

Microsoft InfoCard was the first imaginings of a digital identity token that could be placed in a Wallet. It was a complete failure. Users just didn't want the hassle. Interestingly the content of the InfoCard was nearly that same as a contact, and many users create a contact for themselves, if for no other reason than to send to their correspondents in the way that the InfoCard was imagined to work.
Device Integrity Supporting User Authentication use case approved 2013-12-19 by IDESG.
Whose wallet is it anyway? 2020-04-25 by Anil John of DHS SVIP

In all of the following only those items that impact wallet design, deployment or testing are listed.

There are two distinct approaches to wallet definition:

The narrow approach taken by the Distributed Identity Foundation which starts with the assumption of Blockchain, digital currency, W3C verifiable credentials and the DID core spec operating on their single use didcomm protocol between wallets.
The broad approach taken by standards organizations like OIDF that accommodate all participants like mobile Driver's Licenses and others that operation on existing HTTS networks.

Prepare for digital identity wallets while there is still time

A Cautionary Tale

The HL7 (health) community created a FHIR Smart Wallet; it didn't result in an ecosystem of many competing wallets. The only ones in wide use by consumers today are created by the giants like Epic.

Now we see an effort to by the Open Wallet Foundation to create a broad solution to counter the domination by Apple and Google. The result is a collection (66 in 2024-07-14 and still growing) of non-compatible wallets that have no uptake in the market-place. Somehow the adoption is being pegged to legislation in the EU, Australia, etc. that will create demand in spite of ample evidence that such an approach is not likely to succeed. There is almost no concern in the current proposals to address the user's needs or expectations.

Note that wallets targeting specialized use cases are succeeding in both the health and identity fields, but that does not presage adoption by the general population.

Wallet Architecture

https://github.com/Entidad/architecture-sig/blob/main/docs/architecture/discussions/openwallet_conceptual-model.md

Governance

Governance is an attempt establish in Ecosystem that will satisfy the need of three parties (each of which might have multiple sub parties) that their needs to privacy and security are protected. There is a tension between governments (like the EU) that expect to legislate secure Ecosystems and the evolutionary approach that has always dominated the plans of mice and men by surviving over time and tribulation.^[1]

Governance comes at the wallet from two directions:

Attestations as to the reliability of the wallet code, wherever that might reside,
Evaluation of the process of determining the validity of a credential as it is evaluated by the verifier.

There are three approaches to governance:

The provider of the device creates or evaluates wallet to assure they work on behalf of the user.
The government or other credential issuer supplies the wallet that meets their criteria of security as defined in ISO 18013-5 and others.
A process is created to tell users that independently produces wallets can be trusted by issuers, users and verifiers.

The Open Wallet Foundation has been created to enable the third option.

Verifiable Credentials

From the Verifiable Credentials Data Model 1.0

repository = A program, such as a storage vault or personal verifiable credential Wallet, that stores and protects access to holders' verifiable credentials.
Terms of use - "This feature is also expected to be used by government-issued verifiable credentials to instruct digital wallets to limit their use to similar government organizations in an attempt to protect citizens from unexpected usage of sensitive data."
The ccg SSI folk have created their own proprietary formats in an wallet interop sepc.

W3C DID Core Spec

From the Decentralized Identifiers (DIDs) v1.0 (2021-02-03)

Design Goals

Control = Give entities, both human and non-human, the power to directly control their digital identifiers without the need to rely on external authorities.
Privacy = Enable entities to control the privacy of their information, including minimal, selective, and progressive disclosure of attributes or other *data.
Security = Enable sufficient security for requesting parties to depend on DID documents for their required level of assurance.
Proof-based = Enable DID controllers to provide cryptographic proof when interacting with other entities
Simplicity = Favor a reduced set of simple features to make the technology easier to understand, implement, and deploy.

9.15 Level of Assurance

Additional information about the security context of authentication events is often required for compliance reasons, especially in regulated areas such as the financial and public sectors. Examples include but are not limited to protection of secret keys, the identity proofing process, and the form-factor of the authenticator. For example, Payment services (PSD 2) and eIDAS introduce such requirements to the security context. Level of Assurance (LoA) frameworks are classified and defined by, for example, eIDAS, NIST 800-63-3 and ISO/IEC 29115:2013, including their requirements for the security context, and making recommendations on how to achieve them. This might include strong user authentication and FIDO2/WebAuthn can be potential implementations. A LoA represents the level of confidence that an entity is in fact that entity. Some regulated use cases require the implementation of a certain LoA. Since verification relationships such as assertionMethod and authentication might be used in some of these use cases, information about the applied security context might need to be expressed and provided to a verifier. Whether and how to encode this information in the DID document data model is out of scope for this specification, but it should be noted that the DID document data model can be extended if necessary (see Extensibility section). Section Privacy Considerations remains applicable for such extensions.

10.3 DID Document Correlation Risks

The anti-correlation protections of pseudonymous DIDs are easily defeated if the data in the corresponding DID documents can be correlated. For example, using same public key descriptions or bespoke service endpoints in multiple DID documents can provide as much correlation information as using the same DID. Therefore the DID document for a pseudonymous DID also needs to use pairwise unique public keys. It might seem natural to also use pairwise unique service endpoints in the DID document for a pseudonymous DID. However, unique endpoints allow all traffic between two DIDs to be isolated perfectly into unique buckets, where timing correlation and similar analysis is easy. Therefore, a better strategy for endpoint privacy might be to share an endpoint among thousands or millions of DIDs controlled by many different subjects.

What member think a Wallet Contains

What’s in a Wallet? The recap 2020-07 The Credentials Community Group

Mobile Driver's License

The mDL is an ISO standard that cannot legal be quoted. Here is one person's opinion.

ISO 18013-1 is the card in your wallet right now. It is machine readable. It would not be retired by any means known today.
ISO 18013-5 is the mobile Driver's License. It lives inside an app on your phone as an mdoc (whatever that might mean).
All implementations in North America (2021-02-04) have the state, rather than the federal government or user choice, supply an app.
State-issued apps and driver's license web sites all have sovereign immunity and some, like Texas, have no regard for user privacy.
The reader can ask the phone to prove some set of attributes (eg over 21, state resident)
The app can either get the data or a pointer to the data.
The phone does not leave the user's hands (and thus is not subject to seizure w/o legal basis)
No consensus exists on the means with which the user consents (it might be proximity).
While the use of the standards is limited to a driver's license, actual practices include other things, like access to drugs and alcohol.

The Kantara response with the FIC to the AAMVA RFI.

See the wiki page on Mobile Driver's License for current status. This effort was started by a few states like Louisiana and Colorado with their own proprietary wallets. When the TSA started to accept wallets as Identifier at airports the Apple wallet became the default and then Google and Samsung followed that lead.

Threats

This follows the classical Threat Model design of Howard, Garg and Kohnfelder.

Systemic Threats

By far the largest threat is posed by very concept of a wallet to hold user secrets. This puts users in the habit of allowing their secrets to be held by others. If the concept of wallet is to become a symbol of trust, rather than an infection vector, the industry needs to take early action to ensure that bad actors cannot find a place to inject malware or poorly written code into the security space.
The core cause of the Solar Winds breach of major governmental and commercial web sites was trust in the code that was used to protect the servers on the web. A similar Supply Chain threat is opened by wallets. They will be a magnet for attackers that want to steal user credentials that can be used to infect other parts of the user and the user's navigation to site where they have administrative rights.
An example of system threat is the damage that can be caused by adding extension to browsers, which have become the defect place for collecting and protecting user passwords. Originally password managers were extension, but lately the browsers the selves have hosted password managers, which as limited the market for malware or poorly written managers.
The Vaccine imbroglio present since introduction of a small supply of vaccines into a huge market is bowser extensions like the Washington State Vaccine Locations service. On 2021-02-05 this site would send to you a map of locations were sites like Overlake Hospital Medical Center would send you to a third party signup service that installed a browser extension of unknown provenance. That "sign-up service" insisted on taking over the user's search bar, which is not only a valuable source of links for the service (Google makes most of their money this way), but also yet another source of infection vectors. This same pattern will surely repeat itself when COVID vaccination wallets become available.

Wallet to Credential Provider

Spoofing: In this case the user must be assured that the Credential Provider is trustworthy before it downloads a credential which might be very inappropriate for the user, like saying that the user is a registered pedophile
Tampering: The integrity of the message mandates that the message from the wallet is signed by the wallet and that the Wallet is known to protect the signing key.
Repudiation: The Non-Repudiation feature of a report of a wallet requires there is trustworthy Proof of Presence of the user at the device with suitable time stamping of the transaction.
Information Disclosure: The confidentiality of the interchange requires encryption. If TLS (HTTPS) is used it must be validated that the keying material of RP is trustworthy.
Denial of Service:
Elevation of Privilege:

Wallet to Relying Party

Identity Spoofing: The authenticity if the message depends on the level of assurance that the wallet provides a trustworthy report of the user's intent and that there is trustworthy Proof of Presence of the user at the device.
Tampering: The integrity of the message mandates that the message from the wallet is signed by the wallet and that the Wallet is known to protect the signing key. Also man-in the-middle attacks must be blocked.
Repudiation: The non-reputability of the report from the wallet requires that there is trustworthy Proof of Presence of the user at the device.
Information Disclosure: The confidentiality of the interchange requires encryption. If TLS (HTTPS) is used it must be validated that the keying material of RP is trustworthy.
Denial of Service: Availability of the wallet and the service needs to be high so that the user is not forced to use less secure methods.
Elevation of Privilege: The most common problem will be a web site claiming to be a trustworthy site when it is not. This requires clear indication to the user of a strong identity of the RP web site.

Wallet Application Code

Orie (2021-05-03) For folks on the ID&D call who had trouble following the “JSON-LD Context and Signatures” debate: Here is my summary, @Sam Smith feel free to add your own view, etc…

wallet/v1 -> term IRI is protected by software supply chain (exploitable)
IF wallet/v1 -> term IRI is changed, signatures break (exploit is detectable… but catastrophic).

There were some good questions about how this related to SolarWinds… In that case:

The update was malicious but signed by the correct issuer.
The update altered the function of the software, AND was not detected.
Everything was worse because the update did not cause crashes :slightly_smiling_face:

There are a couple principles hidden in this conversation which are universal:

Always fail loudly (don’t swallow exceptions)
Signature verification does not protect against software supply chain compromise.

What might have helped mitigate solar winds?

independent build servers, handling deterministic builds, and comparing the resulting hash… the compromised server would have differed

…humans could have asked the question…. why is this deterministic build differing in hash?.. maybe we should investigate. Now imagine that the “JSON-LD Canonicalization” process, called “createVerifyData” and described here: https://w3c-ccg.github.io/ldp-bbs2020/#create-verify-data-algorithm Is a kind of independent build…. in that, the code that constructs the verification data, and the code that produces it may be in different languages and on different devices (build servers)… Lets imagine the solar winds hack had changed a context, not a software implementation (which is dumb because its like shoplifting an apple where you will be detected vs a gold bar where you would not)…. In this case, the compromised createVerifyData would produce a different hash, and the signature would fail to verify…. which is good…. of course the attacker might be able to also update the verification algorithm to return true…. which again proves my point…

If your software supply chain is compromised, JSON-LD is the least of your concerns :slightly_smiling_face:
Now its true, that JSON-LD dependency and software implementations of RDF DataSet Normalizations AND createVerifyData are strictly speaking increased attack surface…
similar to implementing a JSON Parser (but worse)… this extra code may be exploitable… and in the infosec community we assume that if a bad thing can happen… it does.

We must then ask the question, how is the attack (we assume it is happening) detected?

This leads us to software supply chain, and https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf

The tools we need to feel safer here are:

Independent deterministic builds
Code Signing
Security Audits of algorithms
Security Audits of implementations
Security Audits of hardware

Tom Jones 1:35 PM thanks Orie - one term of art is policy. The audit typically covers policy and tools rather they trying to see what s/w engineers actually do. (i guess that is what you mean by implementation). So i have actually done all of this and seen it work. It can be done. Step one was missing on solar winds. BUT this has little to do with what we need which is the format / schema on the data that transits from 1) the dev org, 2) the package installer 3) the interaction of the device w/ the s/w. 4) the action of the s/w when signing a bundle, 5) the receipt and validation of the bundle received. 1:37 let’s try to not dig into the details too far on every call or we will make little progress. The one thing missing from the call today was the realization that we need to trust the s/w signing bundles that the verifier needs to trust. 1:42 OH - employee vetting is required including immediate updates of access of terminated employees. (and physical security) - If you ever get to the place where this is needed I can help put it together - i doubt that it belongs in the protocol doc. (edited)

QR Codes

Since Native App Wallets are not able to use the same front-end code that OpenID Connect use to get a good user experience, several schemes have switched to using QR Codes that can invoke any protocol that is supported by the smartphone. While this seems to be good for security, it is well known in 2022-01 that scammers have learned to use it for a variety of subtle attacks against the user.

Other attacks can be seen on the wiki page Quishing.

Physical Security

Particularly in the protection of Digital Assets the protection of private keys in hardware is very attractive, but results in to real threats: (1) the theft of the wallet and the personal attributes needed to access the data on the wallet, and (2) the loss or distraction of the wallet, included loss of use due to changes in the code loaded in security updates to the wallet app.

Requirements

Also known as normative statements.

The first principle is that if it is not documented, then it didn't happen. Be sure that you have the documentation to provide to the team that certifies the app.
Create a good architectural design that includes a risk assessment. (See list of threats above for some ideas.)
Deploy a code management plan so that every line of code can be traced back to a developers check-in.
Secure the supply chain and only sign and deploy code that is validated as meeting Security Risk requirements.
Ensure that the user is never asked to agree to (or to sign) any access that they cannot fully understand. Options MUST be in plain language that is clear and easy for a general audience (typically defined to be an 8th grade education) to understand.
Protect the user's information assets in a manner consistent with the risk. The user's control of the use of the identifier would require the highest level of protection.

Assessment Criteria

Management commitment to the code of conduct.
Development plan.
Data flow diagram suitable for a threat analysis.
Test criteria for each measurable requirement from the spec.

Also see wiki page for Verified Wallet.

EU

https://docs.google.com/document/d/1Dk_8UmytCI4VhCx5VMnXmEzdXRvgJozGeq1GNHZOQik/edit#heading=h.iwmn4jgzxzdy

Canada

https://diacc.ca/wp-content/uploads/2023/04/PCTF-Digital-Wallet_Conformance-Profile-Final-Recommendation-V1.0.pdf

Examples

Not all meet the requirements listed above.

Conexxus Wallet

https://www.conexxus.org/groups/digital-wallet-working-group

Digital Europe Initiative

European Digital Identity as part of the revision of EU Regulation 910/2014 EIDAS 2.0) - Another milestone was reached 2022-08-17

The tender for the Large-Scale Pilots (#LSP) for European Digital Identity Wallets is closing. Two consortia who have applied for these pilots are communicating on their websites about their engagement. It is expected that the consortia will be notified in October or November 2022 if their proposals were accepted.

POTENTIAL is addressing six use cases - SIM eRegistration, Account Opening, eDriving License, eGov Services, eSignature, ePrescription. The website contains short statements on objectives and visions for each use case. The consortium unites 148 participants from 19 EU member states and Ukraine. (WARNING the web site has so little regard for security that is not supporting encryption!)
The NOBID consortium is looking into Wallet issuing, payment means issuance and payment acceptance.

European Commission: Material for the call to provide "Support to the implementation of the European Digital Framework" https://lnkd.in/esZ8bpgU

The Architecture and Reference Framework (ARF) is a set of requirements, recommendations, and specifications for the European Digital Identity (EUDI) Wallet. It was developed by the eIDAS expert group and provides a summary description of the EUDI Wallet concept, including its objectives, roles of the actors of the ecosystem, functional and non-functional requirements, and potential building blocks. The ARF is non-mandatory and does not imply any formal agreement regarding its content or the legislative proposal123.

The European Digital Identity Wallet Toolbox Process is a set of common standards, technical specifications, and guidelines that aim to ensure a high level of trust in digital transactions in Europe. The first version of a common EU Toolbox to implement the EU Digital Identity Wallet was published by the Commission on 10 February 2023. This document, developed by Member States in close collaboration with the Commission, can serve as the technical backbone of all future EU Digital Identity wallets, ensuring their safety, interoperability, and user-friendliness. The Toolbox is non-binding until the legislative proposal on the EU Digital Identity Wallet has been adopted by the co-legislators.^[2]

The High Level Requirements in Annex 2 make it clear that the EUDIW is targeted to on-line access, although it does address proximity wallet connectivity AFTER SOME CONNECTION IS ESTABLISHED. From then on it is wallet-wallet interchanges with OID4VP or mDL.

Idemia Wallet

Idemia is one of a group of identifier providers who have created wallets to extend their business wallet. This wallet is also available pre-installed on some Smartphones like Samsung.^[3]

Apple Wallet

There are no terms and conditions for the wallet above and beyond that for the iPhone. Apple Pay and any card in the wallet does come with terms and conditions that are part of the agreement with the user for those services. Encryption is never mentioned other than in connection with privacy.

Here is a video detailing how the API works: https://developer.apple.com/wwdc22/10041

Here is the documentation that Apple released in mid 2022 that details how to test the API: https://developer.apple.com/documentation/passkit/wallet/requesting_identity_data_from_a_wallet_pass

Apple has provided a few mechanisms to help you test. First, you can test in the iOS Simulator, where the API will return a mock response. This response is similar to a real one, but lacks real signatures.

Similarly, you can use a test profile to receive a mock response on a real iPhone, even If you don't have an ID in Wallet on that iPhone. Details are here: https://developer.apple.com/documentation/passkit/wallet/verifying_wallet_identity_requests

Digital Certificates

The Apple Software contains functionality that allows it to accept digital certificates either issued from Apple or from third parties. YOU ARE SOLELY RESPONSIBLE FOR DECIDING WHETHER OR NOT TO RELY ON A CERTIFICATE WHETHER ISSUED BY APPLE OR A THIRD PARTY. YOUR USE OF DIGITAL CERTIFICATES IS AT YOUR SOLE RISK. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, APPLE MAKES NO WARRANTIES OR REPRESENTATIONS, EXPRESS OR IMPLIED, AS TO MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE, ACCURACY, SECURITY, OR NON-INFRINGEMENT OF THIRD PARTY RIGHTS WITH RESPECT TO DIGITAL CERTIFICATES.

DIACC Wallet specs

The Pan-Canadian Trust Framework PCTF Digital Wallet Component Overview DIACC Wallet follows other DIACC documents in a total lack of any concern for user accessibility. It might have a few ideas about wallets, but nothing useful about users, in particular underserved users, like first nations members. It does mention accessibility as a "nice to have" but nothing about how to achieve it.

Security; Lost or Disabled Devices

Apple Pay stores virtual representations of your Supported Cards and should be protected as you would protect cash or your physical credit, debit, prepaid, rewards, or gift cards. Providing your Device passcode to a third party or allowing a third party to add their fingerprint to use Touch ID or enable Face ID may result in their ability to make payments, send, request, or receive person to person payments, withdraw money from your Apple Cash card, or receive or redeem rewards or credit using Apple Pay on your Device. You are solely responsible for maintaining the security of your Device and of your passcode. You agree that Apple does not have any responsibility if you lose or share access to your Device. You agree that Apple does not have any responsibility if you make unauthorized modifications to the Apple Software (such as by way of a “jailbreak”).You may need to enable additional security measures, such as two-factor authentication for your Apple ID, in order to access particular features of Apple Pay, including Apple Card, the Apple Cash card, and person to person payments with Apple Pay. If you subsequently remove those security features, you may not be able to continue to access particular features of Apple Pay.If your Device is lost or stolen and you have Find My iPhone enabled, you can use Find My iPhone to attempt to suspend the ability to pay with the virtual Supported Payment Cards or sending person to person payments on that Device by putting it into Lost Mode. You can also erase your Device, which will attempt to suspend the ability to pay with the virtual Supported Payment Cards or send person to person payments on the Device and will also attempt to remove the Apple Pay-Enabled Cards. You should also contact the issuer of your Supported Payment Cards, the merchant who issued your Apple Pay-Enabled Cards, or Apple in the case of your Apple Card or Apple Cash card in order to prevent unauthorized access to your Supported Cards.

Google Wallet

A year after launching, Jenny Cheng, VP, General Manager of Google Wallet at Google, joins us to talk about where Wallet has come from and where it's headed. podcast and write-up (2023-07-14)

Google Wallet really is about bringing this all together. So all forms of payments. We just recently announced QR in Brazil, for example, so you can actually use a QR code to make a payment, because it isn't just about being able to tap and pay in every country -- the needs and the type of payments vary widely based on where you are across the globe. ... Ecosystem is absolutely key. We don't only have a consumer app, we really do have to bring along the merchant and partner ecosystem in order to enable that access, so that you have what you need on your phone, and you can actually use it in the store and online as well. ... I'd love to get to the point where the aspects that I think of when you need your wallet has to do with not just payments, but identity as well as those non payment aspects I mentioned -- health insurance cards and transit things you use every day, and then things you use on occasion.

Web Wallet

wallet front-end This application is a user-friendly web wallet that empowers users to manage their digital credentials effortlessly. With a seamless interface and powerful features, users can view their credentials, obtain new ones from issuers, present credentials to verifiers, and access their presentation history. What's missing from many web wallets is any "what you have" authentication factors. Without a user-held device it is difficult to tell how authentication can be secured.

Jolocom

Connect.me

This wallet is provide by Evernym. This is what their website says:

Why can I trust this?
- We don’t own any of your information
  - Zip, zero, zilch. Connect.Me is built on Sovrin, which means you can use your credentials anywhere, even on a different app altogether.
- Your info lives with you
  - Your information isn’t stored in the cloud, it lives in your pocket. So you’re the one in control of your data, where it goes and how it’s used.
- State of the art encryption
  - Connect.Me creates unique, pairwise cryptographic connections to communicate. It's like inventing a new, unique language each time you speak with someone new— and only the two of you understand it.

This is what the app says:

Sophistication and Risk of Cryptographic Systems

By utilizing the Application, User represents and warrants that User understands the inherent risks associated with cryptographic systems and that User has an understanding of the usage and intricacies of key cryptography, native cryptographic tokens, and blockchain-based software systems.

Risk of Weaknesses or Exploits in the Field of Cryptography

The following is a typical wallet T&C in 2023. Hopefully this will improve. Apparently putting legalize in all caps is designed to reinforce their lack of responsibility or accountability.

USER ACKNOWLEDGES AND AGREES THAT CRYPTOGRAPHY IS A PROGRESSING FIELD. ADVANCES IN CODE CRACKING OR TECHNICAL ADVANCES SUCH AS THE DEVELOPMENT OF QUANTUM COMPUTERS MAY PRESENT RISKS TO CRYPTOGRAPHIC SYSTEMS AND THE APPLICATION, WHICH COULD RESULT IN THE THEFT OR LOSS OF YOUR CRYPTOGRAPHIC TOKENS OR PROPERTY. TO THE EXTENT POSSIBLE, EVERNYM INTENDS TO UPDATE THE APPLICATION TO ACCOUNT FOR ANY ADVANCES IN CRYPTOGRAPHY AND TO INCORPORATE ADDITIONAL SECURITY MEASURES BUT DOES NOT GUARANTEE OR OTHERWISE REPRESENT AND/OR WARRANT SECURITY OF THE APPLICATION. BY USING THE APPLICATION, USER ACKNOWLEDGES THESE INHERENT RISKS

USER ACKNOWLEDGES AND AGREES THAT DATA THAT MAY BE INVOLVED IN CONNECTION WITH ANY SERVICE ACCESSIBLE THROUGH USE OF THE APPLICATION IS STORED ON USER’S DEVICE.

USER FURTHER ACKNOWLEDGES AND AGREES THAT USER IS SOLELY RESPONSIBLE FOR SECURELY MAINTAINING:

USER’S TOKENS (INCLUDING CRYPTOGRAPHIC TOKENS);

USERNAME, PASSWORD AND OTHER IDENTITY-RELATED CREDENTIALS;

THE SECURITY OF USER’S DEVICE; AND

SEPARATE BACKUP COPIES OF ANY DATA STORED ON ITS DEVICE INCLUDING WITHOUT LIMITATION ENCRYPTED DATA THAT MAY BE INVOLVED IN CONNECTION WITH ANY SERVICE ACCESSIBLE THROUGH USE OF THE APPLICATION.

Verified.Me

This wallet is from Secure Key and is focused at first on Governments Sign-In Canada. So it comes with an existing user sport system.

The legal documents for this wallet include Privacy Notice, Terms and Conditions, Trademarks, and engagement with credit bureaus. There are no user friendly describes of the privacy or limitations that could be discovered. There are buried descriptions about how it works and support features.

TNO and Findynet

The Open Wallet Foundation has accepted a proposal by Findynet and TNO to take ownership and control of the open-source digital wallet and agent comparison matrix and establish a new special interest group to maintain it. ^[4]

Solutions

Based on some level of hardware support at the user site, there are a wide range of possible solutions.

Concepts for Secure Wallets in Decentralised Identity Ecosystems posted 2023 by Paul Bastian & others at Bundesdruckerei GmbH.
Eleos Labs Quantum resistant crypto primarily for Ethereum.

Devices with Secure Enclave

All ARM and Intel CPUs now have some sort of Trusted Execution Environment included on chip.

Android report from Authenticate 2021-10-19 - Dave Kleidermacher, Google’s VP of Engineering for Android Security outlined what he sees as big challenges of digital safety during his keynote. Those challenges include the need to have simple, strong access control over digital and physical spaces and identity. That’s where he sees digital wallets that benefit from FIDO specifications as being a big help.

Kleidermacher explained that Android devices now offer a digital wallet with a built-in security key. “We’ve worked with the FIDO Alliance to build standard protocols and API’s for developers to incorporate what’s really a miracle of unphishable authentication to any service,” Kleidermacher s

Pluggable Hardware support

This comes in at least two styles:

FIDO 2 keys that contain the means to create a private key per correspondent web site.
USB devices that can off load the secrets, primarily for back-up and restore have been available for at least 20 years.
The Ldeger wallet is a method to store users secrets on an intelligent hardware portable stick. Since it is programable, it is also hackable and exploits have been described.

Examples:

Ledger Nano S Easily start your crypto journey: buy crypto, secure your assets and manage them in one single-app.

Native Apps

The primary feature of a Native App is access to the Secure Enclave..
Both Android and Apple wallets will allow migration of credentials from one of their wallets to another, but not between the two companies.

Cloud Based

These also come in a wide range of support functions from a full wallet implementation to trust service or back-up and restore functionality. They can also implement sharing between to user devices.