| title | description | layout | permalink | sidenav | sticky_sidenav | subnav | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Personal Credential |
Description of Personal Credentials |
page |
/PersonalCredential/ |
secondary |
true |
|
- Digital is not a requirement; it is a choice!
- Eliminate “phone home” architecture/technology/implementations
- Eliminate “back-channel” interactions between verifiers of the credential and the issuer, which are not visible to the credential holder
- Support non-trackable selective disclosure of information under holder control
- Implemented using W3C CCG Verifiable Credential Barcodes [VC-BARCODES]
- Inclusive, global usage without the need for a mobile device
- DHS continues to have no awareness of credential usage by a Customer
- Enhanced content integrity & origin authenticity features on the physical card
- Support for occasionally connected Verifiers – DHS public keys can be resolved, downloaded and cached on the verifying device, using the resolver functionality that is part of the W3C Decentralized Identifiers (DID) standard to allow local verification to occur without network connectivity
- Implemented using W3C Verifiable Credentials Data Model [W3C-VC-DATA-MODEL] and W3C Decentralized Identifiers [W3C-DID]
- Gives the customer agency and control over their data
- Addresses the “phone home” problem in existing identity models
- Provides credential aggregation and selective disclosure with informed consent
- Removes the conflation of identifiers and authenticators
- Supports global resolution of an Issuer’s identifier to its public key(s) & their retrieval
- SHALL NOT implement capabilities that enable tracking of Holder credential use
- SHALL implement the relevant portions of the W3C Web Content Accessibility Guidelines [W3C-WCAG] to ensure compliance with the Section 508 of the U.S. Rehabilitation Act
- SHOULD implement the U.S. Web Design System ( https://designsystem.digital.gov/ )
- SHALL prioritize the implementation of data formats and associated security and privacy mechanisms, inclusive of public facing APIs, that utilize globally available standards and specifications that are openly developed, royalty free and freely available to implement
- SHALL enable the Holder to choose a digital wallet
- SHALL implement support for Holder applications (digital wallets) that use web platform technologies
- SHALL implement support for Holder applications (digital wallets) that use native platform technologies
- SHALL utilize cryptographic modules validated by the joint U.S. & Canada Cryptographic Module Validation Program [CMVP]
- SHALL utilize [FIPS-140] compliant cryptographic key storage mechanisms
- MAY utilize an operating system capability
- MAY utilize an external device capability
- MAY utilize a remote backend capability
- SHALL provide a Software Bill of Materials (SBOM) containing the details and supply chain relationships of various components used in building the Issuer software
- SHALL contain the minimum elements for a SBOM as defined in the joint report by the Department of Commerce and the National Telecommunications and Information Administration
- SHALL implement the [W3C-VC-DATA-MODEL] using the JSON-LD Compacted Document Form
- SHALL implement the embedded proof mechanism defined in [W3C-VC-DATA-INTEGRITY]
- SHALL implement selective disclosure capabilities using [W3C-VC-DATA-INTEGRITY] proof sets to support multiple proofs in a single document
- SHALL implement a proof that is U.S. Federal Information Processing Standards (FIPS) compliant e.g., ECDSA Cryptosuites
- SHALL implement a proof based on non-correlatable signatures e.g., BBS Cryptosuites
- MAY implement additional proofs e.g., PQC
- SHALL implement [W3C-DID]
- SHALL implement the did:web method as the Issuer (Organizational) Identifier
- SHALL utilize the DID Document as the authoritative metadata distribution mechanism
- SHALL implement direct DID resolution
- SHALL implement support for external DID/Metadata resolvers
- SHALL digitally sign the DID Document with a U.S. Federal Information Processing Standards (FIPS) compliant [W3C-VC-DATA-INTEGRITY] proof to enable integrity and provenance verification
- SHALL implement [W3C-BITSTRING-STATUS-LIST] for credential status checks inclusive of revocation checks
- SHALL implement [CITIZENSHIP-VOCAB]
- SHALL NOT implement capabilities that enable Issuer tracking of Holder credential use
- SHALL implement the relevant portions of the W3C Web Content Accessibility Guidelines [W3C-WCAG] to ensure compliance with the Section 508 of the U.S. Rehabilitation Act
- SHOULD implement the U.S. Web Design System ( https://designsystem.digital.gov/ )
- SHALL prioritize the implementation of data formats and associated security and privacy mechanisms, inclusive of public facing APIs, that utilize globally available standards and specifications that are openly developed, royalty free and freely available to implement
- SHALL implement in-context explanations that describe who is accessing credentials, what attributes, capabilities or inferences are accessed, for what purpose the credential is needed, and how data will be used, shared and retained
- SHALL enable the Holder to choose a digital wallet
- SHALL implement support for Holder applications (digital wallets) that use web platform technologies
- SHALL implement support for Holder applications (digital wallets) that use native platform technologies
- SHALL utilize cryptographic modules validated by the joint U.S. & Canada Cryptographic Module Validation Program [CMVP]
- SHALL utilize [FIPS-140] compliant cryptographic key storage mechanisms
- MAY utilize an operating system capability
- MAY utilize an external device capability
- MAY utilize a remote backend capability
- SHALL provide a Software Bill of Materials (SBOM) containing the details and supply chain relationships of various components used in building the Issuer software
- SHALL contain the minimum elements for a SBOM as defined in the joint report by the Department of Commerce and the National Telecommunications and Information Administration
- SHALL implement the [W3C-VC-DATA-MODEL] using the JSON-LD Compacted Document Form
- SHALL implement the embedded proof mechanism defined in [W3C-VC-DATA-INTEGRITY]
- SHALL implement selective disclosure capabilities using [W3C-VC-DATA-INTEGRITY] proof sets to support multiple proofs in a single document
- SHALL implement a proof that is U.S. Federal Information Processing Standards (FIPS) compliant e.g., ECDSA Cryptosuites
- SHALL implement a proof based on non-correlatable signatures e.g., BBS Cryptosuites
- SHALL verify all presented proofs in the proof set
- SHOULD prioritize minimal disclosure of data and metadata by the Holder when negotiating the use of a mutually supported proof, while respecting jurisdictional constraints
- MAY implement additional proofs e.g., PQC
- MAY implement additional credential data formats and associated proof mechanisms
- SHALL implement [W3C-DID]
- SHALL utilize the DID Document as an authoritative source of metadata
- SHALL implement direct DID resolution
- SHALL implement support for external DID/Metadata resolvers
- SHALL digitally verify the U.S. Federal Information Processing Standards (FIPS) compliant [W3C-VC-DATA-INTEGRITY] proof on the DID Document to ensure its integrity and provenance
- SHALL implement [W3C-BITSTRING-STATUS-LIST] for credential status checks including revocation checks
- SHALL implement [CITIZENSHIP-VOCAB]
- SHALL NOT implement capabilities that enable Issuer tracking of Holder credential use
- SHALL implement the relevant portions of the W3C Web Content Accessibility Guidelines [W3C-WCAG] to ensure compliance with the Section 508 of the U.S. Rehabilitation Act
- SHOULD implement the U.S. Web Design System ( https://designsystem.digital.gov/ )
- SHALL prioritize the implementation of data formats and associated security and privacy mechanisms, inclusive of public facing APIs, that utilize globally available standards and specifications that are openly developed, royalty free and freely available to implement
- SHALL implement in-context explanations that describe who is accessing credentials, what attributes, capabilities or inferences are accessed, for what purpose the credential is needed, and how data will be used, shared and retained
- SHALL enable the Holder to choose a digital wallet
- SHOULD be implemented using web platform technologies
- MAY be implemented using native platform technologies
- SHALL utilize cryptographic modules validated by the joint U.S. & Canada Cryptographic Module Validation Program [CMVP]
- SHALL utilize [FIPS-140] compliant cryptographic key storage mechanisms
- MAY utilize an operating system capability
- MAY utilize an external device capability
- MAY utilize a remote backend capability
- SHALL provide a Software Bill of Materials (SBOM) containing the details and supply chain relationships of various components used in building the Issuer software
- SHALL contain the minimum elements for a SBOM as defined in the joint report by the Department of Commerce and the National Telecommunications and Information Administration
- SHALL implement the [W3C-VC-DATA-MODEL] using the JSON-LD Compacted Document Form
- SHALL implement the embedded proof mechanism defined in [W3C-VC-DATA-INTEGRITY]
- SHALL implement selective disclosure capabilities using [W3C-VC-DATA-INTEGRITY] proof sets to support multiple proofs in a single document
- SHALL implement a proof that is U.S. Federal Information Processing Standards (FIPS) compliant e.g., ECDSA Cryptosuites
- SHALL implement a proof based on non-correlatable signatures e.g., BBS Cryptosuites
- SHALL only present one or more proofs supported by the Verifier
- SHOULD prioritize minimal disclosure of data and metadata by the Holder when negotiating the use of a mutually supported proof, while respecting jurisdictional constraints
- MAY implement additional proofs e.g., PQC
- MAY implement additional credential data formats and associated proof mechanisms
- SHALL implement [W3C-DID]
- [W3C-VC-DATA-MODEL] W3C Verifiable Credentials Data Model
- [W3C-VC-DATA-INTEGRITY] W3C Verifiable Credentials Data Integrity
- [W3C-BITSTRING-STATUS-LIST] W3C Bitstring Status List
- [W3C-DID] W3C Decentralized Identifiers
- [W3C-WCAG] W3C Web Content Accessibility Guidelines
- [VC-BARCODES] W3C CCG Verifiable Credential Barcodes
- [CITIZENSHIP-VOCAB] W3C CCG Citizenship Vocabulary
- [FIPS-140] Security Requirements for Cryptographic Modules
- [CMVP] Cryptographic Module Validation Program