Merge pull request #154 from KeychainMDIP/152-keymaster-api-credentials

Added schemas and credentials to Keymaster API
KeychainMDIP · May 23, 2024 · c4c02a0 · c4c02a0
2 parents 73fff11 + 4a8fd51
commit c4c02a0
Show file tree

Hide file tree

Showing 14 changed files with 1,005 additions and 141 deletions.
diff --git a/README.md b/README.md
@@ -43,7 +43,7 @@ Options:
 Commands:
   accept-credential <did> [name]              Save verifiable credential for current ID
   add-name <name> <did>                       Adds a name for a DID
-  attest-credential <file> [registry] [name]  Sign and encrypt a bound credential file
+  issue-credential <file> [registry] [name]  Sign and encrypt a bound credential file
   backup-id                                   Backup the current ID to its registry
   backup-wallet                               Backup wallet to encrypted DID
   bind-credential <file> <did>                Create bound credential for a user

diff --git a/doc/CLI-user-manual/05-credentials.md b/doc/CLI-user-manual/05-credentials.md
@@ -30,7 +30,7 @@ The basic workflow involves three actors: Alice (the Issuer), Bob (the Holder),
 
 1. The Issuer (Alice) creates a Credential. The Credential is like a type or a class; it describes the Credential, and specifies a schema. Each Verified Credential is an instance of a Credential.
 1. The Issuer binds a Credential to a Holder
-1. The Issuer attest a Credential, creating a Verifiable Credential (VC),  by signing and encrypting a Bound Credential.
+1. The Issuer issues a Credential, creating a Verifiable Credential (VC),  by signing and encrypting a Bound Credential.
 1. The Holder (Bob) accepts the VC (adding it to their wallet for future use).
 1. The Verifier (Carol) creates a Challenge. A Challenge is a list of Credentials and trusted Issuers.
 1. The Holder creates a Response to the Challenge. A Response contains a list of Verified Presentations that correspond to the Credentials and trusted Issuers listed in the Challenge. If the User's wallet contains the right Verified Credentials, then it will be possible to create a valid Response to the Challenge. The Response is encrypted for the Verifier.
@@ -190,7 +190,7 @@ $ cat bob-twitter.json
 The credential, bound and populated with the subject's information, must now be signed by the issuer and encrypted to the subject's keys:
 
 ```sh
-$ kc attest-credential bob-twitter.json
+$ kc issue-credential bob-twitter.json
 did:mdip:test:z3v8AuaZAWJuERtD5CwDu2mNpLHjJ6imdNGTwdZpfKY6FK5ASk2
 ```
 
@@ -278,7 +278,7 @@ $ kc show-wallet
 
 ## Revoking a credential
 
-The issuer of a credential can revoke their attestation at any time. This will blank out the VC's credential content data and set the `didDocumentMetadata.deactivated` property to true.
+The issuer of a credential can revoke their credential at any time. This will blank out the VC's credential content data and set the `didDocumentMetadata.deactivated` property to true.
 
 ```sh
 $ kc revoke-credential did:mdip:test:z3v8AuaZAWJuERtD5CwDu2mNpLHjJ6imdNGTwdZpfKY6FK5ASk2
@@ -302,4 +302,4 @@ $ kc resolve-did did:mdip:test:z3v8AuaZAWJuERtD5CwDu2mNpLHjJ6imdNGTwdZpfKY6FK5AS
         "version": 1
     }
 }
-```
+```
diff --git a/doc/CLI-user-manual/06-manifests.md b/doc/CLI-user-manual/06-manifests.md
@@ -4,9 +4,9 @@ sidebar_label: DID Manifest
 slug: manifests
 ---
 
-### 
+###
 
-The DID Manifest is a public data container that is returned with the DID document data. Users can chose to publish or reveal any attestation they receive. All information in the manifest is publicly viewable.
+The DID Manifest is a public data container that is returned with the DID document data. Users can chose to publish or reveal any credential they receive. All information in the manifest is publicly viewable.
 
 Example of `didDocumentData` with a manifest :
 
@@ -42,7 +42,7 @@ Example of `didDocumentData` with a manifest :
 
 ### Publishing a Verifiable Credential
 
-Publishing a VC to a DID Manifest will make it known that the DID holder has received a particular Verifiable Credential without revealing the credential's values. In this example, we know that Bob has a social-media attestation, but we do not know the details:
+Publishing a VC to a DID Manifest will make it known that the DID holder has received a particular Verifiable Credential without revealing the credential's values. In this example, we know that Bob has a social-media credential, but we do not know the details:
 
 ```sh
 $ kc add-name bob-twitter did:mdip:test:z3v8Auaf3eZEUqJEu8xu1uUwxK3ZTLLXsfg9U7p6awPzyuD1AAT
@@ -182,4 +182,4 @@ At any time, a VC holder can decide to remove VCs published on their DID Manifes
 ```sh
 $ kc unpublish-credential bob-twitter
 OK
-```
+```
diff --git a/doc/CLI-user-manual/07-challenge-responses.md b/doc/CLI-user-manual/07-challenge-responses.md
@@ -67,15 +67,15 @@ When presented with a challenge, a user can prepare a Verifiable Presentation of
 
     > [!NOTE]
     >If you're testing as both Alice and Bob from a single wallet, you can skip this step.
-    
+
 1. Then the user can create a repsonse:
 
     ```sh
     $ kc create-response sm-challenge
     did:mdip:test:z3v8AuadZ56m4x2UTpeY3HhSFvFQnrCUyASBYA77vqrqQr9SR99
     ```
 
-The command above mapped the Challenge with previously received VCs and found one matching the request for Bob's twitter account attestation. The resulting DID document contains a Verifiable Presentation revealing the twitter account VC data encrypted to the requesting party (Alice).
+The command above mapped the Challenge with previously received VCs and found one matching the request for Bob's twitter account credential. The resulting DID document contains a Verifiable Presentation revealing the twitter account VC data encrypted to the requesting party (Alice).
 
 ## Verifying a VP Response
 
@@ -113,4 +113,4 @@ kc verify-response did:mdip:test:z3v8AuadZ56m4x2UTpeY3HhSFvFQnrCUyASBYA77vqrqQr9
         }
     }
 ]
-```
+```
diff --git a/doc/CLI-user-manual/README.md b/doc/CLI-user-manual/README.md
@@ -12,7 +12,7 @@ The Keychain-MDIP CLI is a user-facing tool used to interact with the MDIP sub-s
 The Keychain CLI brings together functionality from three important sub-components:
 
 1. Decentralized Identity (DID) registration and management as defined by W3C DID Core.
-1. Verifiable Credential (VC) attestation and management as defined by W3C VC Data Model.
+1. Verifiable Credential (VC) credential and management as defined by W3C VC Data Model.
 1. Crypto keys and wallet management.
 
 All the CLI commands are self-documented using the `--help` flag, or by running `kc` with no flags:
@@ -33,7 +33,7 @@ Options:
 Commands:
   accept-credential <did> [name]              Save verifiable credential for current ID
   add-name <name> <did>                       Adds a name for a DID
-  attest-credential <file> [registry] [name]  Sign and encrypt a bound credential file
+  issue-credential <file> [registry] [name]  Sign and encrypt a bound credential file
   backup-id                                   Backup the current ID to its registry
   backup-wallet                               Backup wallet to encrypted DID
   bind-credential <file> <did>                Create bound credential for a user
@@ -110,4 +110,4 @@ The long string returned starting with `did` will be unique to you. This is your
 
 Think of a DID as a secure reference. Only the owner of the reference can change what it points to. What makes it decentralized is that anyone can discover what it points to without involving a third party.
 
-Creating a new ID automatically creates a new wallet for your ID, which we will describe next.
+Creating a new ID automatically creates a new wallet for your ID, which we will describe next.
diff --git a/doc/DID-scheme/README.md b/doc/DID-scheme/README.md
@@ -311,4 +311,4 @@ function resolveDid(did, asOfTime=now):
 
 For security reasons, MDIP provides no support for storing private keys. We recommend that MDIP clients use BIP-39 to generate a master seed phrase consisting of at least 12 words, and that users safely store the recovery phrase.
 
-If a user loses a device that contains their wallet, they should be able to install the wallet software on a new device, initialize it with their seed phrase and recover their DID along with all their attestations. This implies that a "vault" of the attestations should be stored with the agent DID document, though it should be encrypted with the DID's current private key for privacy.
+If a user loses a device that contains their wallet, they should be able to install the wallet software on a new device, initialize it with their seed phrase and recover their DID along with all their credentials. This implies that a "vault" of the credentials should be stored with the agent DID document, though it should be encrypted with the DID's current private key for privacy.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -311,4 +311,4 @@ function resolveDid(did, asOfTime=now):

		For security reasons, MDIP provides no support for storing private keys. We recommend that MDIP clients use BIP-39 to generate a master seed phrase consisting of at least 12 words, and that users safely store the recovery phrase.

		If a user loses a device that contains their wallet, they should be able to install the wallet software on a new device, initialize it with their seed phrase and recover their DID along with all their attestations. This implies that a "vault" of the attestations should be stored with the agent DID document, though it should be encrypted with the DID's current private key for privacy.
		If a user loses a device that contains their wallet, they should be able to install the wallet software on a new device, initialize it with their seed phrase and recover their DID along with all their credentials. This implies that a "vault" of the credentials should be stored with the agent DID document, though it should be encrypted with the DID's current private key for privacy.