From 4b5b094c2dd304d7eef3acdecdf00b5c94612e38 Mon Sep 17 00:00:00 2001 From: James Chartrand Date: Wed, 29 Oct 2025 08:45:34 -0400 Subject: [PATCH 1/4] add registry and vc help components --- src/RegistryHelp.js | 21 +++++++++++++++++++++ src/VCHelp.js | 5 +++++ 2 files changed, 26 insertions(+) create mode 100644 src/RegistryHelp.js create mode 100644 src/VCHelp.js diff --git a/src/RegistryHelp.js b/src/RegistryHelp.js new file mode 100644 index 0000000..77c92cb --- /dev/null +++ b/src/RegistryHelp.js @@ -0,0 +1,21 @@ +export const VCHelp = () => { + return <> +

To know who issued a Verifiable Credential we must + know who controls the cryptographic key pair (a public key and a private key) used to sign the credential, which typically means + we must be told from a trustworthy source the public key does in fact belong + to the claimed issuer. We can be told directly by the issuer themselves, or they might post it on their well known well + site so we can check it as needed, or they might add it to a registry so that it can be looked up along with the + keys of other issuers. +

+

It is fundamentally necessary that we are told in some trustworthy way that a public key does belong to the issuer. Without that knowledge, + fake key pairs could be used to sign fake credentials and we would not know. +

+

Here, when verifying a credential, we look up public keys in a registry controlled by the Digital Credentials Consortium. + We don't, however, make any guarantees about the trustworthiness or legitimacy of the credentials - only that they + were signed by a key that has been registered in one of our registries. We make no guarantees because this is + strictly for demonstration purposes. A 'real' verifier would use a registry whose entries have been vetted and approved. +

+

A registry of keys controlled by the association of university registrars for a given coountry, for example, + could be used to verify digital degrees from accredited universities

+ +} \ No newline at end of file diff --git a/src/VCHelp.js b/src/VCHelp.js new file mode 100644 index 0000000..dfea944 --- /dev/null +++ b/src/VCHelp.js @@ -0,0 +1,5 @@ +export const VCHelp = () => { + return <> +

A Verifiable Credential is a cryptographically signed digital credential.

+ +} \ No newline at end of file From ccc82c096ff04942bdaf2642cff6bc196d240310 Mon Sep 17 00:00:00 2001 From: James Chartrand Date: Thu, 30 Oct 2025 12:59:30 -0400 Subject: [PATCH 2/4] add expiration date help --- index.js | 4 +++- src/ExpirationDateHelp.js | 15 +++++++++++++++ 2 files changed, 18 insertions(+), 1 deletion(-) create mode 100644 src/ExpirationDateHelp.js diff --git a/index.js b/index.js index a6a970b..ddf6c69 100644 --- a/index.js +++ b/index.js @@ -1 +1,3 @@ -export * from './IssuerHelp'; \ No newline at end of file +export * from './src/IssuerHelp'; +export * from './src/ExpirationDateHelp'; +export * from './src/RegistryHelp'; \ No newline at end of file diff --git a/src/ExpirationDateHelp.js b/src/ExpirationDateHelp.js new file mode 100644 index 0000000..6ba26a0 --- /dev/null +++ b/src/ExpirationDateHelp.js @@ -0,0 +1,15 @@ +export const ExpirationDateHelp = () => { + return <> +

This is mostly straightforward - the credential is considered 'expired' once the given date has passed.

+

The date is set directly in the Verifiable Credential.

+

For version 1 Verifiable Credentials, the date is set like so:

+ 
"expirationDate": "2025-01-09T16:23:24Z"
+

For version 2 Verifiable Credentials, the date is set like so:

+ 
"validUntil": "2025-01-09T16:23:24Z"
+ +

One nuance, though, is that sometimes a credential is still useful even though it has expired. An expired driver's licence, for + example, can still be used to prove our age. Or to prove that we were in fact authorized to drive during a given period, + which might be useful when applying for a job that requires some number of years of driving experience. +

+ +} \ No newline at end of file From 7d21c174433ef5ee14b75f4d4aa5b61e8e00b348 Mon Sep 17 00:00:00 2001 From: James Chartrand Date: Thu, 30 Oct 2025 12:59:58 -0400 Subject: [PATCH 3/4] add non turbopack script for testing --- package.json | 2 -- 1 file changed, 2 deletions(-) diff --git a/package.json b/package.json index a5dc2dc..f6dcc35 100644 --- a/package.json +++ b/package.json @@ -2,8 +2,6 @@ "name": "@digitalcredentials/vc-help-react", "description": "React components providing contextual help content (text/images) for Verifiable Credentials", "version": "1.0.0", - "scripts": { -}, "type": "module", "module": "./index.js", "exports": { From 758c9f56bb4056f821bcd4682c894288fffd1c1d Mon Sep 17 00:00:00 2001 From: James Chartrand Date: Thu, 30 Oct 2025 13:00:16 -0400 Subject: [PATCH 4/4] update help text --- src/IssuerHelp.js | 5 +---- src/RegistryHelp.js | 12 ++++++------ 2 files changed, 7 insertions(+), 10 deletions(-) diff --git a/src/IssuerHelp.js b/src/IssuerHelp.js index 35f7dbe..7c64697 100644 --- a/src/IssuerHelp.js +++ b/src/IssuerHelp.js @@ -1,9 +1,6 @@ export const IssuerHelp = () => { return <> -

The issuer is the person or institution that issued the Verifiable Credential. - This might be, for example, a university that has granted a degree to a student - and subsequently then issued a Verifiable Credential attesting that the student did earn the degree.

-

The issuer usually also signs the credential, but in some cases a third party might sign on the issuer's behalf.

+

The issuer is the person or institution that issued the Verifiable Credential, for example, a university that gives students Verifiable Credentials confirming their graduation.

Fundmentally important is that to trust anything signed by an issuer, the DID (Decentralized Identififer) used to sign the credential must be known to us in some way. That might be because diff --git a/src/RegistryHelp.js b/src/RegistryHelp.js index 77c92cb..f4de006 100644 --- a/src/RegistryHelp.js +++ b/src/RegistryHelp.js @@ -1,16 +1,16 @@ -export const VCHelp = () => { +export const RegistryHelp = () => { return <>

To know who issued a Verifiable Credential we must know who controls the cryptographic key pair (a public key and a private key) used to sign the credential, which typically means - we must be told from a trustworthy source the public key does in fact belong - to the claimed issuer. We can be told directly by the issuer themselves, or they might post it on their well known well - site so we can check it as needed, or they might add it to a registry so that it can be looked up along with the + we must be told from a trustworthy source that the public key does in fact belong + to the claimed issuer. We can be told directly by the issuer themselves, which can be as a simple as saying, "Hey there, my DID is did:key:z6MkjoriXdbyWD25YXTed114F8hdJrLXQ567xxPHAUKxpKkS" or they might post it on their known + web site (e.g. mit.edu) so we can check it as needed, or they might add it to a registry so that it can be looked up along with the keys of other issuers.

It is fundamentally necessary that we are told in some trustworthy way that a public key does belong to the issuer. Without that knowledge, - fake key pairs could be used to sign fake credentials and we would not know. + fake key pairs could be used to sign fake credentials and we just wouldn't know.

-

Here, when verifying a credential, we look up public keys in a registry controlled by the Digital Credentials Consortium. +

In this app, when verifying a credential, we look up public keys in a registry controlled by the Digital Credentials Consortium. We don't, however, make any guarantees about the trustworthiness or legitimacy of the credentials - only that they were signed by a key that has been registered in one of our registries. We make no guarantees because this is strictly for demonstration purposes. A 'real' verifier would use a registry whose entries have been vetted and approved.