Wallet

From MgmtWiki
Revision as of 09:30, 4 February 2021 by Tom (talk | contribs) (Context and History)

Jump to: navigation, search

Full Title or Meme

The Wallet is a word with a common well-known meaning in real-life repurposed for use in Identity Management.

Context and History

  • Microsoft Info Card was the first imaginings of a digital identity token that could be placed in a Wallet. It was a complete failure.
  • Whose wallet is it anyway? 2020-04-25 by ANIL JOHN of DHS SVIP

NSTIC Principles

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 user - "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."

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.

Mobile Driver's License

Threats

Wallet to Credential Proivder

Wallet to Relying Party

Requirements

This list is just a SWAG.

  1. 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.
  2. Create a good architectural design that includes a risk assessment. (See list of threats above for some ideas.)
  3. Deploy a code management plan so that every line of code can be traced back to a developers check-in.
  4. Secure the supply chain and only sign and deploy code that is validated a meeting security risk requirements.
  5. 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.
  6. 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.

Examples

Not all meet the requirements listed above.

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.

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.

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.

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

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.

References