Merge pull request #183 from wip-abramson/feature/update-cred-issuanc…

…e-language

WIP refactor issuance protocol text

spec/data_flow_issuance.md

@@ -23,6 +23,7 @@ sequenceDiagram
   I ->> I: Verify Credential Request
   I ->> I: Issue Credential
   I ->> H: Send Credential
+  H ->> H: Remove Credential Blinding
   H ->> H: Verify and Store Credential
 
 
@@ -35,7 +36,7 @@ The [[ref: issuer]] prepares a [[ref: Credential Offer]] for the [[ref: holder]]
 
 Using the data from the [[ref: Credential Offer]] and the [[ref: Public Credential Definition]] retrieved from the [[ref: Verifiable Data Registry]], the [[ref: holder]] prepares a [[ref: Credential Request]] (step 8), a formal request to the [[ref: issuer]] to issue a [[ref: credential]] based on the given [[ref: Public Credential Definition]] to the [[ref: holder]]. The [[ref: Credential Request]] includes a cryptographic commitment to the [[ref: holder]]'s [[ref: link secret]]. The [[ref: holder]] sends the [[ref: Credential Request]] to the [[ref: issuer]] (step 9).
 
-The [[ref: issuer]] verifies and decides whether to accept the [[ref: Credential Request]] (step 10) and if so, prepares the [[ref: credential]] (step 11). The [[ref: issuer]] sends the [[ref: credential]] to the [[ref: holder]] (step 12), who verifies the [[ref: credential]] and (usually) securely stores it (step 13).
+The [[ref: issuer]] verifies and decides whether to accept the [[ref: Credential Request]] (step 10) and if so, prepares the [[ref: credential]] (step 11). The [[ref: issuer]] sends the [[ref: credential]] to the [[ref: holder]] (step 12). The [[ref: holder]] then removes the blinding factor from the credential (step 13), verifies the [[ref: credential]] and (usually) securely stores it (step 14).
 
 Details about each step in the issuance process are covered in the following sections.
 
@@ -117,13 +118,13 @@ the [[ref: Credential Offer]] and verify the consistency between the list of
 attributes in the [[ref: Schema]] and in the [[ref: Public Credential
 Definition]].
 
+In addition, the [[ref: holder]] also requires access to their [[ref: link
+secret]].
+
 The nonce of the [[ref: Credential Offer]] is used to generate the proof of correctness
 for blinded credential secrets, where it is hashed with the blinded secrets to
 create the proof which is sent to the [[ref: issuer]].
 
-In addition, the [[ref: holder]] also requires access to their [[ref: link
-secret]].
-
 #### Verifying the Key Correctness Proof
 
 The [[ref: holder]] must first verify the `key_correctness_proof` in the [[ref:
@@ -134,7 +135,7 @@ section](#credential-offer) about the [[ref: Credential Offer]].
 The `key_correctness_proof` verification is as follows:
 
 1. Check that all attributes in [[ref: Public Credential Definition]] and `master_secret` (an
-   attribute that will be related to the [[ref: link_secret]]) are included in
+   attribute that will be related to the [[ref: link secret]]) are included in
    `xr_cap`.
 1. Compute $c'$, where  $c' = H(z || {r_i}  || \hat{z'} ||\hat{r_i'})$.
 1. If $\hat{z'} == \tilde{z}$ and $\hat{r_i'} == \tilde{r_i}$, then $c' == c$. The proof is accepted.
@@ -200,26 +201,28 @@ Once constructed, the [[ref: holder]] sends the [[ref: Credential Request]] to t
 
 #### Blinding the Link Secret
 
-The `blinded_ms` ([[ref: blinded link secret]]) in the `Credential Request` is a
-cryptographic commitment by the [[ref: holder]] to the link secret. The
-`blinded_ms` will be signed by the [[ref issuer]], placed in the credential, and
-during presentations, is proven by the [[ref holder]] to be associated with the
-[[ref: link_secret]] using a proof of knowledge, without revealing the [[ref:
-link_secret]] itself. This is the capability that enables the binding of the
-credential to the holder without revealing a correlatable identifier.
+The [[ref: holder]] generates a [[ref: blinding factor]] and uses this to create a cryptographic commitment to their [[ref: link secret]]. This is the `blinded_ms` ([[ref: blinded link secret]]) in the `Credential Request`. The `blinded_ms` will be signed by the [[ref issuer]] along with the rest of the credential attributes to create a blinded Signature. The [[ref: holder]] removes the [[ref: blinding factor]] from the blinded Signature to retrieve the Credential Signature over their unblinded [[ref: link secret]] and the credential attributes. 
+
+
+During presentations, the [[ref: holder]] can prove knowledge of the [[ref: link secret]] within credential or set of credentials being presented, without revealing the [[ref: link secret]] itself. This is the capability that enables the binding of the
+credentials to each other and to the [[ref: holder]] without revealing a correlatable identifier.
+
+::: todo
+
+Confirm purpose of the blinding factor and add how it is generated.
+
+:::
 
-The [[ref: blinding factor]] is a secret held by the [[ref: holder]] for blinding
-the [[ref: link secret]] before sending it to the [[ref: issuer]], and used later
-when generating the proof of knowledge that the [[ref: link secret]] was used in
-the signature received from the [[ref: issuer]]. The [[ref: blinding factor]],
-$v$ is created by [[ref: holder]].
+The [[ref: blinding factor]] is a secret generated by the [[ref: holder]] for blinding
+the [[ref: link secret]] before sending it to the [[ref: issuer]]. The [[ref: blinding factor]],
+$v$ is created by selecting a random integer that is less than the order of the RSA group, `n`.
 
 The process of blinding the link secret uses the [[ref: issuer]]'s
 `CredentialPrimaryPublicKey`, $P$, which is included in the [[ref: Public Credential Definition]],
 and contains `z`, `r`, `s` and `n` (described
 [here](#generating-a-cred_def-without-revocation-support)). While `r` contains
 the public keys for all of the attributes to be signed, the only one of interest
-in this process is $r_{link secret}$
+in this process is $r_{link_secret}$
 
 The [[ref: link secret]], $A_l$ is blinded by
 

spec/data_flow_setup.md

@@ -268,7 +268,7 @@ signatures generated with the respective private key. The length of the block of
 messages, `L`, being signed is defined by referencing a specific Schema with a
 certain number of attributes, `A = a1,a2,..` and setting `L` to `A+1`. The
 additional message being signed as part of a credential is for a `link_secret`
-(called the [[ref: link_secret]] everywhere except in the existing open source
+(called the [[ref: link secret]] everywhere except in the existing open source
 code and data models) attribute which is included in all credentials. This value
 is blindly contributed to the credential during issuance and used to bind the
 issued credential to the entity to which it was issued.
@@ -643,13 +643,12 @@ To prepare to use AnonCreds credentials, the [[ref: Holder]] must create a
 [[ref: link secret]], a unique identifier that allows credentials issued to a
 [[ref: Holder]] to be bound to that [[ref: Holder]] and presented without
 revealing a unique identifier, thus avoiding correlation of credentials by
-[[ref: Verifier]]s. The [[ref: link_secret]] is kept private by the [[ref:
+[[ref: Verifier]]s. The [[ref: link secret]] is kept private by the [[ref:
 Holder]]. The [[ref: link secret]] is used during the credential issuance
 process to bind the credential to the [[ref: holder]] and in the generation of a
 presentation. For the latter, it allows the [[ref: holder]] to create a zero
-knowledge proof that they were issued the credential by demonstrating knowledge
-of the value of the [[ref: link_secret]] without sharing it. The details of how
-the [[ref: link_secret]] is used to do this is provided in the issuance,
+knowledge proof that they were issued the credential.This proof demonstrates knowledge the [[ref: link secret]] and prove that it is one of the signed credential attributes, without revealing the [[ref: link secret]] to the [[ref: verifier]]. The details of how
+the [[ref: link secret]] is used to do this is provided in the issuance,
 presentation generation and verification sections of this specification.
 
 The [[ref: link secret]] is a sufficiently random unique identifier. For
@@ -658,21 +657,21 @@ produced by a call to the Rust
 [uuid](https://docs.rs/uuid/0.5.1/uuid/index.html) Crate's `new_v4()` method to
 achieve sufficient randomness.
 
-Once generated, the [[ref: link_secret]] is stored locally by the [[ref:
+Once generated, the [[ref: link secret]] is stored locally by the [[ref:
 Holder]] for use in subsequent issuance and presentation interactions. If lost,
 the [[ref: Holder]] will not be able to generate a proof that the credential was
 issued to them. The [[ref: holder]] generates only a single [[ref:
-link_secret]], using it for all credentials the [[ref: holder]] is issued. This
+link secret]], using it for all credentials the [[ref: holder]] is issued. This
 allows for [[ref: verifier]]s to verify that all of the credentials used in
 generating a presentation with attributes from multiple credentials were all
 issued to the same [[ref: Holder]] without requiring the [[ref: Holder]] to
-disclose the unique identifier ([[ref: link_secret]]) that binds these
+disclose the unique identifier ([[ref: link secret]]) that binds these
 credentials together.
 
 There is nothing to stop a [[ref: Holder]] from generating multiple [[ref:
-link_secret]]s and contributing them to different credential issuance processes.
+link secret]]s and contributing them to different credential issuance processes.
 However, doing so prevents the [[ref: Holder]] from producing a presentation
-combining credentials issued to distinct [[ref: link_secret]]s that can be
+combining credentials issued to distinct [[ref: link secret]]s that can be
 proven to have been issued to the same entity. It is up to the [[ref: Verifier]]
 to require and enforce the binding between multiple credentials used in a
 presentation.

spec/introduction.md

@@ -6,8 +6,11 @@ AnonCreds ZKP verifiable credentials provide capabilities that many see as impor
 - Complete flows for issuing verifiable credentials (Issuer to Holder), and requesting, generating and verifying presentations of verifiable claims (Holder to Verifier).
 - Fully defined data models for all of the objects in the flows, including verifiable credentials, presentation requests and presentations sourced from multiple credentials.
 - Fully defined applications of cryptographic primitives.
+- The use of a Blind Signature scheme in the issuance process to enhance the privacy protections available to the holder recieving the credential, including:
+  - Only the holder learns the final credential signature, the issuer only learns a blinded version which only the holder can unblind.
+  - The issuer can sign messages blindly, never learning their value, while still being able to guarantee that the holder knows the value of the message being signed. This is used for the link secret, which the holder commits to during the issuance, the issuer blindly signs this message along with the rest of the credential attributes and then the holder removes the blinding to get a signature over the credential attributes including the unblinded link secret value.
 - The use of Zero Knowledge Proofs (ZKPs) in the verifiable presentation process to enhance the privacy protections available to the holder in presenting data to verifiers, including:
-  - Blinding issuer signatures to prevent correlation based on those signatures.
+  - Proving that certain values are part of a signed credential without revealing them including: credential signature, link secret and any attributes a holder does not wish to reveal. This helps prevent correlation based on these values.
   - The use of unrevealed identifiers for holder binding to prevent correlation based on such identifiers.
   - The use of predicate proofs to reduce the sharing of PII and potentially correlating data, especially dates (birth, credential issuance/expiry, etc.).
   - A revocation scheme that proves a presentation is based on credentials that have not been revoked by the issuers without revealing correlatable revocation identifiers.
@@ -25,8 +28,8 @@ AnonCreds require a [[ref: Verifiable Data Registry]] (VDR). A [[ref: VDR]] (box
 
 Based on a [[ref: Schema]], arbitrary [[ref: Issuer]]s (box in yellow) can create a Credential Definition ([[ref: Credential Definition]]) which references the [[ref: Schema]]. A [[ref: Credential Definition]] enables [[ref: Issuers]] to issue AnonCreds [[ref: Credentials]] to [[ref: Holders]] and enables [[ref:Verifier]]s (box in red) to verify [[ref: Credentials]] issued to and presented by a [[ref:Holder]]. A [[ref: Credential Definition]] consists of two pieces of information: First, the [[ref: Private Credential Definition]] includes the private signing keys of the [[ref:Issuer]] for signing and issuing AnonCreds [[ref: Credentials]] to [[ref: holders]] and is kept private by the [[ref: Issuer]]. Second, the [[ref: Public Credential Definition]] includes the public keys of the [[ref:Issuer]], has to be stored on a [[ref:VDR]] and is used by [[ref: holders]] and arbitrary [[ref:Verifiers]] in order to verify AnonCreds [[ref: Credentials]] issued to and presented by [[ref: Holders]].
 
-Each [[ref: Holder]] (box in blue) has a [[ref: link secret]], which enables [[ref: Credential]] to [[ref: Holder]] binding: Whenever a [[ref: Credential]] is issued to a [[ref: Holder]] by an [[ref: Issuer]], the [[ref: Holder]] sends a blinded version of the [[ref: link secret]] to the [[ref: Issuer]] before the credential is issued to the [[ref: Holder]]. The blinded version of the [[ref: link secret]] gets then signed along with the other attributes within the AnonCreds [[ref: Credential]] by the [[ref: Issuer]] and sent to the [[ref: Holder]]. Since the [[ref:Holder]] uses a blinded version of the same [[ref:link secret]] for every [[ref: Credential]] that is issued to the [[ref: Holder]], the [[ref: Holder]] can proof the affiliation of multiple [[ref:Credentials]] at presentation time.
+Each [[ref: Holder]] (box in blue) has a [[ref: link secret]], which enables [[ref: Credential]] to [[ref: Holder]] binding: Whenever a [[ref: Credential]] is issued to a [[ref: Holder]] by an [[ref: Issuer]], the [[ref: Holder]] generates a [[ref: blinding factor]] and uses this to commit to a blinded version of the [[ref: link secret]] which is sent to the [[ref: Issuer]]. The [[ref: Issuer]] verifies the commitment, before producing a blind signature over the blinded [[ref: link secret]] along with the other attributes within the AnonCreds [[ref: Credential]]. This blind signature is sent to the [[ref: Holder]], who removes the [[ref: blinding factor]] to retrieve a credential signature over the [[ref: Credential]] attributes including the unblinded [[ref: link secret]]. By using the same [[ref:link secret]] for every [[ref: Credential]] that is issued to the [[ref: Holder]], the [[ref: Holder]] can prove the affiliation of multiple [[ref:Credentials]] at presentation time.
 
-[[ref: Holders]] never present the raw signed credential data they received from [[ref: Issuers]] to [[ref: Verifiers]] for verification purposes. Instead a [[ref: Verifiable Presentation]] is created by the [[ref: Holder]] and sent to the [[ref: Verifier]]. A [[ref: Verifiable Presentation]] is a derivation of an AnonCreds [[ref: Credential]] which allows a [[ref: Holder]] to proof the correctness of the revealed credential data, without revealing the original raw credential signature(s). [[ref: Verifiers]] process [[ref: Verifiable Presentation]]s for verification of [[ref: credential]] data.
+[[ref: Holders]] never present the raw signed credential data they - received from [[ref: Issuers]] - to [[ref: Verifiers]] for verification purposes. Instead a [[ref: Verifiable Presentation]] is created by the [[ref: Holder]] and sent to the [[ref: Verifier]]. A [[ref: Verifiable Presentation]] is a derivation of an AnonCreds [[ref: Credential]] which allows a [[ref: Holder]] to proof the correctness of the revealed credential data, without revealing the original raw credential signature(s). Additionally, [[ref: Holders]] prove knowledge the [[ref: link secret]] attribute within the [[ref: Credential]], without revealing this value to the [[ref: Verifiers]]. [[ref: Verifiers]] process [[ref: Verifiable Presentation]]s for verification of [[ref: credential]] data.
 
 AnonCreds allows the revocation of [[ref: Credentials]] issued to [[ref: Holders]] by [[ref: Issuers]]. In case revocation is required, at least one ([[ref: Revocation Registry Definition]]), which references the associated [[ref: Public Credential Definition]], has to be stored to the [[ref: VDR]] by the [[ref: Issuer]] in addition to the [[ref: Public Credential Definition]]. A [[ref: Revocation Registry Definition]] can have [[ref: Revocation Status List]]s. When one or more credentials have to be revoked, the [[ref: Issuer]] stores a [[ref: Revocation Status List]] with the updated status of the credentials in question to the [[ref: VDR]]. [[ref: Holder]] use these additional pieces of information in order to generate a [[ref:Non-Revocation Proof]]. A [[ref:Non-Revocation Proof]] proves to a [[ref:Verifier]], that the credential the [[ref:Holder]] presented to the [[ref:Verifier]], has not been revoked. [[ref: Verifiers]] use the information provided by a [[ref:Revocation Registry Definition]] and associated [[ref: Revocation Status List]]s to verify the [[ref: Holder]]`s [[ref:Non-Revocation Proof]]. A [[ref: Tails File]] supports the revocation mechanism. Each [[ref: Revocation Registry Definition]] requires exactly one Tails File.