Difference between revisions of "Verifiable Credential"
From MgmtWiki
(→Problems) |
(→Full Title or Meme) |
||
| (27 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | + | The [https://www.w3.org/TR/vc-data-model/ Verifiable Credentials Data Model 1.0] is a standard means fro create a collection of claims to move between trust domains or federations. But since is it a data model and not a data format or protocol, it cannot deliver on that goal. | |
| − | == | + | The [https://www.w3.org/TR/vc-data-model-2.0/#names-and-descriptions Verifiable Credentials Data Model v2.0] is close to publication 2024-02 it adds features like display language for fields that make it even harder to comply with than V1. |
| + | |||
| + | ==Context== | ||
* The [[Verifiable Credential]] was the first of a series of proposed standards to enable [[Self-Sovereign Identity]] by enabling the packaging of user identity information that can be verified by the receiver. | * The [[Verifiable Credential]] was the first of a series of proposed standards to enable [[Self-Sovereign Identity]] by enabling the packaging of user identity information that can be verified by the receiver. | ||
| − | * The Verifiable [[Presentation]] is | + | * The Verifiable [[Presentation]] is created in response to a request from a [[Verifier]] which is known here as a [[Relying Party]]. |
| + | ===Taxonomy=== | ||
| + | The current behaviors of SameSite are: | ||
| + | {|border="1" padding="2" width="799px" | ||
| + | | Term || Meaning or Behavior | ||
| + | |- | ||
| + | | claim || An assertion made about a subject. (This can only be considered true if the term subject is interpreted very broadly.) | ||
| + | |- | ||
| + | |subject || A thing about which claims are made.(Complete circulate - no real meaning at all.) | ||
| + | |- | ||
| + | | user agent || A program, such as a browser or other Web client, that mediates the communication between holders, issuers, and verifiers. (This does not match DID core well at all.) | ||
| + | |- | ||
| + | |validation|| The assurance that a verifiable credential or a verifiable presentation meets the needs of a verifier and other dependent stakeholders. | ||
| + | |} | ||
==Problems== | ==Problems== | ||
| Line 11: | Line 26: | ||
The Swiss Army knife was designed for survival in the wild if it were the only tool available to you. | The Swiss Army knife was designed for survival in the wild if it were the only tool available to you. | ||
* It was wildly popular and sold or copied throughout the world. | * It was wildly popular and sold or copied throughout the world. | ||
| − | * The Swiss Army knife is not used to fix a car our build a house if there are | + | * The Swiss Army knife is not used to fix a car our build a house if there are purpose-built tools available. |
The [[Verifiable Credential]] spec was created to allow [[Verifiable Credential]]s to fill any identify function. | The [[Verifiable Credential]] spec was created to allow [[Verifiable Credential]]s to fill any identify function. | ||
| − | * | + | * It is wildly popular among hackers who want to be able to create quick-and-dirly soltuions. |
| + | * It is not designed to architect or build industrial scale identifier/attribute solutions. | ||
| + | |||
| + | ===User Control=== | ||
| + | User control is mentioned as non-normative in the VC spec. It is not required, in fact this appears in the VC Spec. “Placing a refreshService property in a verifiable credential so that it is available to verifiers can remove control and consent from the holder and allow the verifiable credential to be issued directly to the verifier, thereby bypassing the holder.” The DID Core spec specifically declaims any definition of control leaving it up to the user and the method. For example this quote “Each DID document can express cryptographic material, verification methods, or services, which provide a set of mechanisms enabling a DID controller to prove control of the DID.” Most DID methods just enable proof of possession of a private key by the signing of any response at all. This feature is then incorrectly conflated with proof of control. | ||
==Solutions== | ==Solutions== | ||
===interoperability=== | ===interoperability=== | ||
| − | * This [https://www.evernym.com/blog/getting-to-practical-interop-with-verifiable-credentials/ Evernym atricle] seems to be saying both that it does not exist and it is right around the corner. (2020-12-21) | + | * The Open Wallet Foundation has been constituted in 2023 to allow interoperability, but server no other purpose, like keeping user secrets safe or getting informed consent from the user. |
| + | * The [https://speakerdeck.com/jhenderson/vc-api-at-owf VC API spec deck] described (2023-04-24) a VC lifecycle where only the interchange of messages between agents is described. Also no consideration if the holder is at all protected. | ||
| + | * This [https://www.evernym.com/blog/getting-to-practical-interop-with-verifiable-credentials/ Evernym atricle] seems to be saying both that it does not exist and it is right around the corner. (2020-12-21) [https://www.w3.org/TR/vc-data-model/ The W3C recommendation] is dated 2019-11-19. | ||
| + | |||
| + | ===Version 1.1=== | ||
| + | [https://www.w3.org/TR/2021/REC-vc-data-model-20211109/ Verifiable Credentials v1].1 has just been released[1] for public review and a W3C Advisory Committee vote[2]: | ||
| + | |||
| + | There are three (fairly boring but important and backwards compatible): | ||
| + | substantive changes in this version of the specification: | ||
| + | # Update previous normative references that pointed to RFC3339 for datetime details to now normatively reference the datetime details described in XMLSCHEMA11-2 which more accurately reflects the usage in examples and libraries. | ||
| + | # Loosen the requirement to use URLs to use URIs in the id property of the credentialStatus and refreshService sections of the data model. Link normatively to the URI specification. | ||
| + | # Loosen normative statements in the zero-knowledge proofs section to enable compliance of new zero-knowledge proof schemes, such as BBS+, that have been created since the v1.0 specification was published as a Recommendation. | ||
| + | |||
| + | The W3C Advisory Committee vote was open until 2021-01-28. | ||
| + | |||
| + | The general public is invited to view and comment on the proposed corrections during this time period. Proposed corrections are marked up like so: | ||
| + | |||
| + | https://www.w3.org/TR/2021/REC-vc-data-model-20211109/#c1_1 | ||
| + | |||
| + | This publication is also a signal to the market that the Verifiable Credentials specification is under regular maintenance and is tracking the realities in the market as it evolves. | ||
| + | |||
| + | * The context schema is at | ||
| + | * The normative sections have been abstracted here [[Verifiable Cred V1.1 Normative]]. | ||
| + | |||
| + | ===Commercial Product=== | ||
| + | * [https://www.newswire.com/news/idramp-announces-passwordless-credential-orchestration-manager-is-now-21562624 Idramp offers VC backed ID for access to Oracle] 2021-11-24 | ||
==References== | ==References== | ||
| Line 24: | Line 68: | ||
[[Category: Glossary]] | [[Category: Glossary]] | ||
[[Category: Standard]] | [[Category: Standard]] | ||
| + | [[Category: Credential]] | ||
Latest revision as of 18:35, 24 February 2024
Contents
Full Title or Meme
The Verifiable Credentials Data Model 1.0 is a standard means fro create a collection of claims to move between trust domains or federations. But since is it a data model and not a data format or protocol, it cannot deliver on that goal.
The Verifiable Credentials Data Model v2.0 is close to publication 2024-02 it adds features like display language for fields that make it even harder to comply with than V1.
Context
- The Verifiable Credential was the first of a series of proposed standards to enable Self-Sovereign Identity by enabling the packaging of user identity information that can be verified by the receiver.
- The Verifiable Presentation is created in response to a request from a Verifier which is known here as a Relying Party.
Taxonomy
The current behaviors of SameSite are:
| Term | Meaning or Behavior |
| claim | An assertion made about a subject. (This can only be considered true if the term subject is interpreted very broadly.) |
| subject | A thing about which claims are made.(Complete circulate - no real meaning at all.) |
| user agent | A program, such as a browser or other Web client, that mediates the communication between holders, issuers, and verifiers. (This does not match DID core well at all.) |
| validation | The assurance that a verifiable credential or a verifiable presentation meets the needs of a verifier and other dependent stakeholders. |
Problems
The Verifiable Credential is a Swiss Army knife
The Swiss Army knife was designed for survival in the wild if it were the only tool available to you.
- It was wildly popular and sold or copied throughout the world.
- The Swiss Army knife is not used to fix a car our build a house if there are purpose-built tools available.
The Verifiable Credential spec was created to allow Verifiable Credentials to fill any identify function.
- It is wildly popular among hackers who want to be able to create quick-and-dirly soltuions.
- It is not designed to architect or build industrial scale identifier/attribute solutions.
User Control
User control is mentioned as non-normative in the VC spec. It is not required, in fact this appears in the VC Spec. “Placing a refreshService property in a verifiable credential so that it is available to verifiers can remove control and consent from the holder and allow the verifiable credential to be issued directly to the verifier, thereby bypassing the holder.” The DID Core spec specifically declaims any definition of control leaving it up to the user and the method. For example this quote “Each DID document can express cryptographic material, verification methods, or services, which provide a set of mechanisms enabling a DID controller to prove control of the DID.” Most DID methods just enable proof of possession of a private key by the signing of any response at all. This feature is then incorrectly conflated with proof of control.
Solutions
interoperability
- The Open Wallet Foundation has been constituted in 2023 to allow interoperability, but server no other purpose, like keeping user secrets safe or getting informed consent from the user.
- The VC API spec deck described (2023-04-24) a VC lifecycle where only the interchange of messages between agents is described. Also no consideration if the holder is at all protected.
- This Evernym atricle seems to be saying both that it does not exist and it is right around the corner. (2020-12-21) The W3C recommendation is dated 2019-11-19.
Version 1.1
Verifiable Credentials v1.1 has just been released[1] for public review and a W3C Advisory Committee vote[2]:
There are three (fairly boring but important and backwards compatible): substantive changes in this version of the specification:
- Update previous normative references that pointed to RFC3339 for datetime details to now normatively reference the datetime details described in XMLSCHEMA11-2 which more accurately reflects the usage in examples and libraries.
- Loosen the requirement to use URLs to use URIs in the id property of the credentialStatus and refreshService sections of the data model. Link normatively to the URI specification.
- Loosen normative statements in the zero-knowledge proofs section to enable compliance of new zero-knowledge proof schemes, such as BBS+, that have been created since the v1.0 specification was published as a Recommendation.
The W3C Advisory Committee vote was open until 2021-01-28.
The general public is invited to view and comment on the proposed corrections during this time period. Proposed corrections are marked up like so:
https://www.w3.org/TR/2021/REC-vc-data-model-20211109/#c1_1
This publication is also a signal to the market that the Verifiable Credentials specification is under regular maintenance and is tracking the realities in the market as it evolves.
- The context schema is at
- The normative sections have been abstracted here Verifiable Cred V1.1 Normative.
Commercial Product
References
- This was one of the highlights from XXXI Internet Identity workshop:(IIW) presentation by Timothy Ruff (https://lnkd.in/gXDRGMy).
