Verifiable Credential - Revision history

Tom: /* Context */

2024-11-16T00:36:44Z

‎Context

Tom: /* Student Creds */

2024-05-31T18:22:10Z

‎Student Creds

Tom: /* Student Creds */

2024-05-31T18:21:48Z

‎Student Creds

Tom: /* Student Creds= */

2024-05-31T18:20:55Z

‎Student Creds=

Tom: /* Commercial Product */

2024-05-31T18:20:42Z

‎Commercial Product

Tom: /* Full Title or Meme */

2024-02-25T01:35:27Z

‎Full Title or Meme

Tom: /* Full Title or Meme */

2024-02-25T01:32:12Z

‎Full Title or Meme

Tom: /* Solutions */

2023-04-30T23:55:16Z

‎Solutions

Tom: /* interoperability */

2023-04-30T23:50:25Z

‎interoperability

Tom: /* User Control */

2023-04-30T23:18:48Z

‎User Control

@@ Line 7: / Line 7: @@
 * 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:

@@ Line 74: / Line 74: @@
 Hiring managers benefit from more trusted data. Candidates benefit from enhanced prospects in competitive job markets and portable credentials they can use elsewhere.
-Post by Drummond Reed 2025-05-31. Congrats to the team at National Student Clearinghouse for helping making this happen. It’s just the first step in our longer journey to unlock the full potential of digital wallets. Cc @Marie Wallace, @Colin Strasburg, @Lexi Ashpole, Didier Serra.
+Post by Drummond Reed 2024-05-31. Congrats to the team at National Student Clearinghouse for helping making this happen. It’s just the first step in our longer journey to unlock the full potential of digital wallets. Cc @Marie Wallace, @Colin Strasburg, @Lexi Ashpole, Didier Serra.
 ==References==

@@ Line 74: / Line 74: @@
 Hiring managers benefit from more trusted data. Candidates benefit from enhanced prospects in competitive job markets and portable credentials they can use elsewhere.
-Post by Drummond Reed Congrats to the team at National Student Clearinghouse for helping making this happen. It’s just the first step in our longer journey to unlock the full potential of digital wallets. Cc @Marie Wallace, @Colin Strasburg, @Lexi Ashpole, Didier Serra.
+Post by Drummond Reed 2025-05-31. Congrats to the team at National Student Clearinghouse for helping making this happen. It’s just the first step in our longer journey to unlock the full potential of digital wallets. Cc @Marie Wallace, @Colin Strasburg, @Lexi Ashpole, Didier Serra.
 ==References==

@@ Line 62: / Line 62: @@
 ===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
-==Student Creds===
+===Student Creds===
 Serious adoption of #VerifiableCredentials will come when (a) the benefits are clear for all parties involved, and (b) the experience is 10x better than the status quo.

@@ Line 62: / Line 62: @@
 ===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==

@@ Line 2: / Line 2: @@
 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
+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==

@@ Line 35: / Line 35: @@
 ===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 [https://speakerdeck.com/jhenderson/vc-api-at-owf VC API spec deck] described (2023094-24) a VC lifecycle where only the interchange of messages between agents is described. Also no consideration if the holder is at all protected.
+* 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.

@@ Line 34: / Line 34: @@
 ==Solutions==
 ===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) [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]:

@@ Line 30: / Line 30: @@
 ===User Control===
-User control is mentioned non normatively 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 is then incorrectly conflated with proof of 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==