From 657ea5dfe8a0259d7b9f7d4dc74f130edf780161 Mon Sep 17 00:00:00 2001 From: Luc Date: Tue, 21 May 2024 16:19:26 +0000 Subject: [PATCH 1/7] Introduce Draft --- docs/ensip/draft-vc.mdx | 78 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 docs/ensip/draft-vc.mdx diff --git a/docs/ensip/draft-vc.mdx b/docs/ensip/draft-vc.mdx new file mode 100644 index 000000000..1ae4bfe54 --- /dev/null +++ b/docs/ensip/draft-vc.mdx @@ -0,0 +1,78 @@ +{/** @type {import('@/lib/mdxPageProps').MdxMetaProps} */} +export const meta = { + description: 'A standard for verifiable credentials in text records in ENS', + contributors: [ + 'luc.eth', + ], + ensip: { + status: 'draft', + created: '2024-05-21', + } +}; + +# ENSIP-XX: Verifiable Credentials / Presentations + +### Abstract + +This ENSIP aims to standardize the usage of Verifiable Credentials & Presentations within ENS records. + +### Motivation + +With the increasing prevalence of self-custodial digital identity & attestation solutions, it is of importance to have a standardized way to publicly share verifiable credentials using your ENS profile. + +### Specification + +#### Example + +An example of a verifiable credential including ENS audience + +```json +// this example is wip +{ + "@context": [ + "https://www.w3.org/2018/credentials/v1" + ], + "type": [ + "VerifiablePresentation" + ], + "verfiableCredential": [ + { + "@context": [ + "https://www.w3.org/2018/credentials/v1", + "https://www.w3.org/2018/credentials/examples/v1" + ], + "id": "https://credentials.dentity.com/credentials/1234", + "type": [ + "VerifiableCredential", + "ProofOfTwitterCredential" + ], + "issuer": { + "id": "did:example:dentity" + }, + "issuanceDate": "2000-00-00T00:00:00Z", + "twitter": "lucemansnl", + ... + "proof": { + ... + } + } + ], + "id": "12345", + "holder": "did:ens:luc.eth", + "proof": { + ... + } +} +``` + +### Backwards Compatibility + +This ENSIP relies on the existing ENS text record functionality introduced in [ENSIP-5](/ensip/5), and only standardizes the usage of the specific `verifications` record. + +### Security Considerations + +None. + +### Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 482a7647ef0439a5ec96c6ab001fc53f23841d88 Mon Sep 17 00:00:00 2001 From: Luc Date: Tue, 21 May 2024 17:00:08 +0000 Subject: [PATCH 2/7] Bump --- docs/ensip/draft-vc.mdx | 43 +++++++++++++++++++++++++++++++++++++++-- 1 file changed, 41 insertions(+), 2 deletions(-) diff --git a/docs/ensip/draft-vc.mdx b/docs/ensip/draft-vc.mdx index 1ae4bfe54..04a292eee 100644 --- a/docs/ensip/draft-vc.mdx +++ b/docs/ensip/draft-vc.mdx @@ -14,7 +14,7 @@ export const meta = { ### Abstract -This ENSIP aims to standardize the usage of Verifiable Credentials & Presentations within ENS records. +This ENSIP aims to standardize the usage of [W3C Verifiable Credentials & Presentations](https://www.w3.org/TR/vc-data-model-2.0/) within ENS records. ### Motivation @@ -22,9 +22,39 @@ With the increasing prevalence of self-custodial digital identity & attestation ### Specification +#### Verifications in Profiles + +Defines the use of the `verifications` record. +This record aims to store a list of verifiable credentials or did's, pointing towards certain credentials + +#### Draft + +did/url links to vc +vc contains **metadata** **claims** & **proof** +implementations choose what "proof"s they support (aka, what credentials they accept/trust) +claims are the actual data thats being attested + #### Example -An example of a verifiable credential including ENS audience +An example of a verifiable credential + +```json +{ + "@context": [ + "https://www.w3.org/2018/credentials/v1", + "https://schema.org/" + ], + "id": "https://example.com/credentials/3847", + "type": ["VerifiableCredential"], + "issuanceDate": "2019-01-01T19:23:24Z", + "credentialSubject": { + "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", + "knows": "did:example:6f1c276e12ec21ebfeb1f712ebc" + } +} +``` + +f ```json // this example is wip @@ -65,6 +95,15 @@ An example of a verifiable credential including ENS audience } ``` +### Considerations + +#### Revocation & Expiration + +Verifiable Credentials are meant to be used as long-lived documents. +However this does not mean that they can't be revoked or expired. +In a similar manner to physical documents, a credentials validity can be checked by contacting the issuer. +The implementation of verification is specific to each issuer, however can be inferred from `verificationMethod` in the credential. + ### Backwards Compatibility This ENSIP relies on the existing ENS text record functionality introduced in [ENSIP-5](/ensip/5), and only standardizes the usage of the specific `verifications` record. From 2f3cd296e235cdaf36f61c56a9f1451c98208097 Mon Sep 17 00:00:00 2001 From: Luc Date: Tue, 21 May 2024 18:09:35 +0000 Subject: [PATCH 3/7] Bump --- docs/ensip/draft-vc.mdx | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/docs/ensip/draft-vc.mdx b/docs/ensip/draft-vc.mdx index 04a292eee..8667565cf 100644 --- a/docs/ensip/draft-vc.mdx +++ b/docs/ensip/draft-vc.mdx @@ -10,7 +10,7 @@ export const meta = { } }; -# ENSIP-XX: Verifiable Credentials / Presentations +# ENSIP-XX: Verifiable Credentials & Presentations ### Abstract @@ -22,18 +22,18 @@ With the increasing prevalence of self-custodial digital identity & attestation ### Specification -#### Verifications in Profiles - -Defines the use of the `verifications` record. -This record aims to store a list of verifiable credentials or did's, pointing towards certain credentials - -#### Draft +#### Very Rough Draft did/url links to vc vc contains **metadata** **claims** & **proof** implementations choose what "proof"s they support (aka, what credentials they accept/trust) claims are the actual data thats being attested +#### Verifications in Profiles + +Defines the use of the `verifications` record. +This record aims to store a list of verifiable credentials or did's, pointing towards certain credentials + #### Example An example of a verifiable credential @@ -101,8 +101,12 @@ f Verifiable Credentials are meant to be used as long-lived documents. However this does not mean that they can't be revoked or expired. -In a similar manner to physical documents, a credentials validity can be checked by contacting the issuer. -The implementation of verification is specific to each issuer, however can be inferred from `verificationMethod` in the credential. +In a similar manner to physical documents, a credentials validity can be checked by contacting the issuer (Think of how a store might only look at your drivers license, while a car dealership would run it through a computer). + +The implementation of verification is specific to each issuer, and can be inferred from `verificationMethod` in the credential. +In addition to the `expirationDate` field, which causes the credential to invalidate after a certain date. + +This means that identity platforms can allow users to revoke (or expand) credentials without needing to modify the records in ENS. ### Backwards Compatibility From 97a86de0a671ab234931fa22270a959604b2b281 Mon Sep 17 00:00:00 2001 From: Luc Date: Tue, 21 May 2024 18:11:23 +0000 Subject: [PATCH 4/7] Bump --- docs/ensip/draft-vc.mdx | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/docs/ensip/draft-vc.mdx b/docs/ensip/draft-vc.mdx index 8667565cf..f74322554 100644 --- a/docs/ensip/draft-vc.mdx +++ b/docs/ensip/draft-vc.mdx @@ -39,14 +39,14 @@ This record aims to store a list of verifiable credentials or did's, pointing to An example of a verifiable credential ```json +// this example is wip { "@context": [ - "https://www.w3.org/2018/credentials/v1", - "https://schema.org/" + "https://www.w3.org/2018/credentials/v1" ], "id": "https://example.com/credentials/3847", "type": ["VerifiableCredential"], - "issuanceDate": "2019-01-01T19:23:24Z", + "issuanceDate": "2024-05-21T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "knows": "did:example:6f1c276e12ec21ebfeb1f712ebc" @@ -54,7 +54,7 @@ An example of a verifiable credential } ``` -f +or in the form of a presentation: ```json // this example is wip @@ -62,9 +62,7 @@ f "@context": [ "https://www.w3.org/2018/credentials/v1" ], - "type": [ - "VerifiablePresentation" - ], + "type": ["VerifiablePresentation"], "verfiableCredential": [ { "@context": [ From 08653fbb54ad4e9d26840178b051afc84c2e5c6c Mon Sep 17 00:00:00 2001 From: Luc Date: Thu, 1 Aug 2024 10:31:45 +0000 Subject: [PATCH 5/7] Bump --- docs/ensip/draft-vc.mdx | 33 +++++++++++++++++++++++++++------ 1 file changed, 27 insertions(+), 6 deletions(-) diff --git a/docs/ensip/draft-vc.mdx b/docs/ensip/draft-vc.mdx index f74322554..96eb3f4a1 100644 --- a/docs/ensip/draft-vc.mdx +++ b/docs/ensip/draft-vc.mdx @@ -34,6 +34,28 @@ claims are the actual data thats being attested Defines the use of the `verifications` record. This record aims to store a list of verifiable credentials or did's, pointing towards certain credentials +Examples of these records would be: + +``` +https://myapp.com/credentials/1234.json +https://api.myapp.com/verifications/1234?token=abc123 +// ipfs +// did +``` + +#### Credentials & Presentations + +The documents stored in the `verifications` record are verifiable credentials or presentations following the [W3C Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/). +These credentials are JSON-LD documents that contain a set of claims, metadata, and proof, signed by the issuer. + +#### End-User Experience + +The end-user experience of this ENSIP is to allow users to publicly share their verifiable credentials in a standardized way. +Users visit an app that lets them create a verifiable credential, and then share the link to that credential in their ENS profile. + +Name Manager Applications can then read these credentials and display them in a user-friendly way. +As well as allow for setting/revoking credentials. + #### Example An example of a verifiable credential @@ -45,11 +67,10 @@ An example of a verifiable credential "https://www.w3.org/2018/credentials/v1" ], "id": "https://example.com/credentials/3847", - "type": ["VerifiableCredential"], + "type": ["VerifiableCredential", ""], "issuanceDate": "2024-05-21T00:00:00Z", "credentialSubject": { - "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", - "knows": "did:example:6f1c276e12ec21ebfeb1f712ebc" + "id": "did:ens:luc.eth", } } ``` @@ -75,13 +96,13 @@ or in the form of a presentation: "ProofOfTwitterCredential" ], "issuer": { - "id": "did:example:dentity" + "id": "did:ens:idp.eth" }, "issuanceDate": "2000-00-00T00:00:00Z", "twitter": "lucemansnl", - ... "proof": { - ... + "verificationMethod": "did:ens:idp.eth", + "signature": "..." } } ], From 7ea3cb7f7da348d72d7c6f788a2c7c77fa96b7f7 Mon Sep 17 00:00:00 2001 From: Luc Date: Tue, 6 Aug 2024 12:00:19 +0000 Subject: [PATCH 6/7] Update VC Spec --- docs/ensip/draft-vc.mdx | 129 +++++++++++++++++----------------------- 1 file changed, 54 insertions(+), 75 deletions(-) diff --git a/docs/ensip/draft-vc.mdx b/docs/ensip/draft-vc.mdx index 96eb3f4a1..8bdfbe99c 100644 --- a/docs/ensip/draft-vc.mdx +++ b/docs/ensip/draft-vc.mdx @@ -1,16 +1,16 @@ {/** @type {import('@/lib/mdxPageProps').MdxMetaProps} */} export const meta = { - description: 'A standard for verifiable credentials in text records in ENS', - contributors: [ - 'luc.eth', - ], - ensip: { - status: 'draft', - created: '2024-05-21', - } + description: 'A standard for verifiable credentials in text records in ENS', + contributors: [ + 'luc.eth', + ], + ensip: { + status: 'draft', + created: '2024-05-21', + } }; -# ENSIP-XX: Verifiable Credentials & Presentations +# ENSIP-20: Verifiable Credentials in ENS ### Abstract @@ -19,28 +19,19 @@ This ENSIP aims to standardize the usage of [W3C Verifiable Credentials & Presen ### Motivation With the increasing prevalence of self-custodial digital identity & attestation solutions, it is of importance to have a standardized way to publicly share verifiable credentials using your ENS profile. +Allowing for easy sharing of verifiable credentials right on your profile. ### Specification -#### Very Rough Draft - -did/url links to vc -vc contains **metadata** **claims** & **proof** -implementations choose what "proof"s they support (aka, what credentials they accept/trust) -claims are the actual data thats being attested - #### Verifications in Profiles Defines the use of the `verifications` record. -This record aims to store a list of verifiable credentials or did's, pointing towards certain credentials - -Examples of these records would be: +This record aims to store a list of verifiable credentials or did's, pointing towards certain credentials. +Under ideal circumstances this record relies on a yet to be written ENSIP that allows for multidimensional records. +However in its current state assumes that the `verifications` record contains an abi encoded `string[]` of verifiable credentials. ``` https://myapp.com/credentials/1234.json -https://api.myapp.com/verifications/1234?token=abc123 -// ipfs -// did ``` #### Credentials & Presentations @@ -48,26 +39,13 @@ https://api.myapp.com/verifications/1234?token=abc123 The documents stored in the `verifications` record are verifiable credentials or presentations following the [W3C Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/). These credentials are JSON-LD documents that contain a set of claims, metadata, and proof, signed by the issuer. -#### End-User Experience - -The end-user experience of this ENSIP is to allow users to publicly share their verifiable credentials in a standardized way. -Users visit an app that lets them create a verifiable credential, and then share the link to that credential in their ENS profile. - -Name Manager Applications can then read these credentials and display them in a user-friendly way. -As well as allow for setting/revoking credentials. - -#### Example - -An example of a verifiable credential - ```json -// this example is wip { "@context": [ "https://www.w3.org/2018/credentials/v1" ], - "id": "https://example.com/credentials/3847", - "type": ["VerifiableCredential", ""], + "id": "https://example.com/credentials/1234", + "type": ["VerifiableCredential"], "issuanceDate": "2024-05-21T00:00:00Z", "credentialSubject": { "id": "did:ens:luc.eth", @@ -75,65 +53,66 @@ An example of a verifiable credential } ``` -or in the form of a presentation: +Note the requirement for `id` to be `did:ens:luc.eth` in order to prevent credential spoofing. -```json -// this example is wip -{ - "@context": [ - "https://www.w3.org/2018/credentials/v1" - ], - "type": ["VerifiablePresentation"], - "verfiableCredential": [ - { - "@context": [ - "https://www.w3.org/2018/credentials/v1", - "https://www.w3.org/2018/credentials/examples/v1" - ], - "id": "https://credentials.dentity.com/credentials/1234", - "type": [ - "VerifiableCredential", - "ProofOfTwitterCredential" - ], - "issuer": { - "id": "did:ens:idp.eth" - }, - "issuanceDate": "2000-00-00T00:00:00Z", - "twitter": "lucemansnl", - "proof": { - "verificationMethod": "did:ens:idp.eth", - "signature": "..." - } - } - ], - "id": "12345", - "holder": "did:ens:luc.eth", - "proof": { - ... - } +#### End-User Experience + +This method allows users to publicly share their verifiable credentials in a standardized way. +Users can visit an app that lets them create a verifiable credential, and then share the link to that credential in their ENS profile. + +Name Manager Applications can then read, and iterate over these credentials and display them in a user-friendly way. +As well as allow for setting/removing/revoking credentials. + +#### Developer Experience + +{/* TODO: Reword */} +From the front-end developer perspective reading verifiable credentials is as simple as (name, predicate): + +```tsx +const { credentials } = useVC('luc.eth', (c) => c.type == 'TelegramCredential'); +``` + +#### Resolver Interface + +Although no resolver modifications are required to support this ENSIP, it is recommended to implement a resolver interface that allows for easier and more gas-efficient adding and removing of verifiable credentials. + +```solidity +interface IVerifiableCredentialResolver { + function addCredentials(bytes32 node, bytes[] calldata data) external; + function removeCredentials(bytes32 node, uint256[] indexes) external; +} + +// TODO: Solidity Arrays vs Abi Encoded +interface IVerifiableCredentialMultiResolver { + function addCredential(bytes32 node, bytes[] calldata data) external; + function removeCredential(bytes32 node, uint256[] indexes) external; } ``` +After performing a removeCredential operation it is recommended to re-fetch the credentials record to ensure your app shows the correct order. + ### Considerations #### Revocation & Expiration Verifiable Credentials are meant to be used as long-lived documents. However this does not mean that they can't be revoked or expired. -In a similar manner to physical documents, a credentials validity can be checked by contacting the issuer (Think of how a store might only look at your drivers license, while a car dealership would run it through a computer). +In a similar manner to physical documents, a credentials validity can be checked by contacting the issuer or verifying a signature. The implementation of verification is specific to each issuer, and can be inferred from `verificationMethod` in the credential. -In addition to the `expirationDate` field, which causes the credential to invalidate after a certain date. +In addition to the `expirationDate` field, which causes the credential to automatically invalidate after a certain date. This means that identity platforms can allow users to revoke (or expand) credentials without needing to modify the records in ENS. ### Backwards Compatibility This ENSIP relies on the existing ENS text record functionality introduced in [ENSIP-5](/ensip/5), and only standardizes the usage of the specific `verifications` record. +It imposes forwards compatibility by allowing for future upgrading of record dimensionality while maintaining backwards compatibility. ### Security Considerations -None. +All verifiable credentials stored in a profile or on a blockchain should be assumed to be public and unverified data. +Platforms should decide for themselves what issuers they trust and what credentials they allow and filter for those credentials. ### Copyright From 3a0f79fe1f3523af957a420ddfe9ad84334287ee Mon Sep 17 00:00:00 2001 From: Luc Date: Tue, 27 Aug 2024 16:51:56 +0000 Subject: [PATCH 7/7] Update Spec --- docs/ensip/draft-vc.mdx | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/docs/ensip/draft-vc.mdx b/docs/ensip/draft-vc.mdx index 8bdfbe99c..5ef59cb7c 100644 --- a/docs/ensip/draft-vc.mdx +++ b/docs/ensip/draft-vc.mdx @@ -28,7 +28,7 @@ Allowing for easy sharing of verifiable credentials right on your profile. Defines the use of the `verifications` record. This record aims to store a list of verifiable credentials or did's, pointing towards certain credentials. Under ideal circumstances this record relies on a yet to be written ENSIP that allows for multidimensional records. -However in its current state assumes that the `verifications` record contains an abi encoded `string[]` of verifiable credentials. +However in its current state assumes that the `verifications` **record contains an abi encoded** `string[]` **of verifiable credentials**. ``` https://myapp.com/credentials/1234.json @@ -39,22 +39,24 @@ https://myapp.com/credentials/1234.json The documents stored in the `verifications` record are verifiable credentials or presentations following the [W3C Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/). These credentials are JSON-LD documents that contain a set of claims, metadata, and proof, signed by the issuer. +Note the requirement for `id` to be `did:ens:luc.eth` in order to prevent credential spoofing. + ```json { "@context": [ - "https://www.w3.org/2018/credentials/v1" + "https://www.w3.org/2018/credentials/v1", + "https://www.w3.org/2018/credentials/examples/v1" // your custom context ], "id": "https://example.com/credentials/1234", "type": ["VerifiableCredential"], "issuanceDate": "2024-05-21T00:00:00Z", "credentialSubject": { - "id": "did:ens:luc.eth", + "id": "did:ens:luc.eth", // the subject's ens name + "isCool": "definitely", // your custom field } } ``` -Note the requirement for `id` to be `did:ens:luc.eth` in order to prevent credential spoofing. - #### End-User Experience This method allows users to publicly share their verifiable credentials in a standardized way. @@ -65,16 +67,20 @@ As well as allow for setting/removing/revoking credentials. #### Developer Experience -{/* TODO: Reword */} From the front-end developer perspective reading verifiable credentials is as simple as (name, predicate): ```tsx const { credentials } = useVC('luc.eth', (c) => c.type == 'TelegramCredential'); ``` +Under the hood this will resolve to the `verifications` record, which is a `string[]` abi encoded. + #### Resolver Interface Although no resolver modifications are required to support this ENSIP, it is recommended to implement a resolver interface that allows for easier and more gas-efficient adding and removing of verifiable credentials. +An example of such is the proposed below. + +It is assumed that credential data is stored in an unsorted set, and that indexes can be used to remove credentials. ```solidity interface IVerifiableCredentialResolver {