Verifiable credentials Verifiable credentials (VCs) are digital credentials which follow the relevant World Wide Web Consortium open standards. They can represent information found in physical credentials, such as a passport or license, as well as new things that have no physical equivalent, such as ownership of a bank account. They have numerous advantages over physical credentials, most notably that they're digitally signed, which makes them tamper-resistant and instantaneously verifiable.[1][2] Verifiable credentials can be issued by anyone, about anything, and can be presented to and verified by everyone. The entity that generates the credential is called the Issuer. The credential is then given to the Holder who stores it for later use. The Holder can then prove something about themselves by presenting their credentials to a Verifier. Trust modelThe holder of a verifiable credential operates in a triangle of trust,[3] mediating between issuer and verifier.
Any role in the triangle can be played by a person, an institution, or a machine. Note that because verifiable credentials can be created by anyone, the verifier decides if they trust the issuer. DecentralizationThe VC model places the holder of a credential at the center of the identity ecosystem, giving individuals control of their identity attributes. The W3C VC model parallels physical credentials: the user holds cards and can present them to anyone at any time without informing or requiring the permission of the card issuer. Such a model is decentralized and gives much more autonomy and privacy to the participants. This contrasts with the federated identity management (FIM) model, as adopted by SAML and OpenID Connect, which place the identity provider (IdP) in the central role as the dispenser of identity attributes and the determiner of which Service Providers (SPs) it will give them to. In the federated model, the IdP knows every SP that the user visits. Verifiable Credentials Data Model 1.0The data model for verifiable credentials is a World Wide Web Consortium (W3C) Recommendation, "Verifiable Credentials Data Model 1.0 - Expressing verifiable information on the Web", published 19 November 2019.[4] CompositionVerifiable Credentials may be expressed using JSON and is typically composed of:
{
"verifiableCredential": {
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "0892f680-6aeb-11eb-9bcf-f10d8993fde7",
"type": [
"VerifiableCredential",
"UniversityDegreeCredential"
],
"issuer": {
"id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
"name": "Acme University"
},
"issuanceDate": "2021-05-11T23:09:06.803Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science"
}
},
"proof": {
"type": "Ed25519Signature2018",
"created": "2021-05-17T15:25:26Z",
"jws": "eyJhbGciOiJFZERTQYjY0Il19..nlcAA",
"proofPurpose": "assertionMethod",
"verificationMethod": "https://pathToIssuerPublicKey"
}
}
}
AliasesThe VC context, defined using the {
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/14",
"issuanceDate": "2010-01-01T19:23:24Z",
"expirationDate": "2020-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
},
"proof": {
}
}
W3C VCs are extensible. Any new property can be added to VCs, as determined by the issuer. Standard properties have been defined specifically as extension points. These include the following:
SubjectThe holder of a VC does not always have to be the subject of the credential. It is expected that most users will hold their own VCs, i.e., the holder and the subject will be the same entity. This need not always be the case. For example, when the VC subject is an infant, and the VC is a birth certificate, the holder may be one or both parents.[5] ProofsNo proof mechanism is standardized but the data model is flexible enough to support various existing cryptographic mechanisms, such as digital signatures. Proof mechanisms that are in use include: JSON Web Tokens with JSON Web Signatures, JSON-LD proofs, and zero-knowledge proofs using schemes such as IBM's anonymous credentials. TransportVarious protocols are specified for carrying VCs from the issuer/IdP to the holder, and the holder to the verifier. Examples include:
None of these protocols has become standardized. Many people who are experimenting with VCs use HTTPS to carry VCs between the various parties. Criticisms and concernsThe security of verifiable credentials in the context of COVID-19 vaccination and test certificates has been questioned.[9][10] Verifiable credentials have also been subject to usability concerns.[11] Some have likened anyone being able to issue a verifiable credential being like a shop clerk deciding if they should accept an out-of-state license as proof of age when purchasing alcohol. See alsoReferences
|
Portal di Ensiklopedia Dunia
