Base Proof

In order to add a selective disclosure base proof to a document the issuer needs the following cryptographic key material:

1. The issuers private/public key pair, i.e., the key pair corresponding to the verification method that will be part of the proof.
2. A per proof private/public key pair created by the issuer just for this proof. This is an ephemeral, single use key pair where the private key is not kept after the proof has been generated.
3. An HMAC key. This used to randomize the order of the blank node ids to avoid potential information leakage from the blank node id ordering. This is used only once and is shared between issuer and holder. The HMAC in this case is functioning as a pseudorandom function (PRF).

The key material used for generating the add base proof test vectors is shown below. Multibase representation is use for the P-256 key pairs and the HMAC key is given as a hexadecimal string.

In our scenario a person will be issued an employment authorization document as shown below.

The mandatory information as specified by the issuer is specified via an array of JSON pointers as shown below.

The result of applying the above JSON pointers to the employment authorization document is shown below.

Transformation of the unsigned document begins with canonicalizing the document as shown below.

To prevent possible information leakage from the ordering of the blank node ids these are processed through a PRF, i.e., the HMAC to give the canonized HMAC document shown below. This represents an ordered list of statements that will be subject to mandatory and selective disclosure, i.e., it is from this list that statements are grouped.

The above canonical document gets grouped in to mandatory and non-mandatory statements. The final output of the selective disclosure transformation process is shown below. Each statement is now grouped as mandatory and non-mandatory and its index in the previous list of statements is remembered.

The next step is to create the base proof configuration and canonicalize it. This is shown in the following two examples.

In the hashing step we compute the SHA-256 hash of the canonicalized proof options to produce the `proofHash` and we compute the SHA-256 hash of the join of all the mandatory nquads to produce the `mandatoryHash`. These are shown below in hexadecimal format.

We compute the `baseSignature` over the concatenation of the `proofHash`, `proofPublicKey`, and `mandatoryHash` using the issuers long term `privateKey`. We compute the `signatures` array by signing each non-mandatory nquad using the per `proofPrivateKey`. These signatures, the `proofPublicKey`, and `mandatoryPointers` which are fed to the final serialization step are shown below.

Finally, the values above are run through the algorithm of [[[VC-DATA-INTEGRITY-1.1#SerializeBase-SIC]]] to produce the `proofValue` which is used in the signed based document shown below.

Derived Proof

In order to create a derived proof a holder starts with a signed document containing a base proof. The base document we will use for these test vectors is the final example from Section [[[#base-proof]]] above. The first step is to run the algorithm of [[[VC-DATA-INTEGRITY-1.1#ParseBase-SIC]]] to recover `baseSignature`, `publicKey`, `hmacKey`, `signatures`, and `mandatoryPointers` as shown below.

Next, the holder needs to indicate what, if anything else, they wish to reveal to the verifiers by specifying JSON pointers for selective disclosure.

To produce the `revealDocument`, i.e., the unsigned document that will eventually be signed and sent to the verifier, we append the selective pointers to the mandatory pointers and input these combined pointers along with the document without proof to the algorithm of [[[VC-DATA-INTEGRITY-1.1#selectjsonld]]] to give the result shown below.

Now that we know what the revealed document looks like, we need to furnish appropriately updated information to the verifier on which statements are mandatory, the signatures for the selected non-mandatory statements, and the mapping between canonical blank node ids for the reveal document and a subset of the HMAC blank node ids. Running step 6 of the [[[VC-DATA-INTEGRITY-1.1#CreateDisclosureData]]] yields an abundance of information about various statement groups relative to the original document. Below we show a portion of the indexes for those groups.

The verifier needs to be able to aggregate and hash the mandatory statements. To enable this we furnish them with a list of indexes of the mandatory statements adjusted to their positions in the reveal document. In the previous example the `combinedIndexes` show the indexes of all the original nquads (statements) that make up the reveal document, in order. To come up with the adjusted mandatory indexes shown below we obtain the index of each of original mandatory indexes relative to the `combinedIndexes` as shown below.

We have to furnish the verifier with a list of signatures for those selective statements (nquads) that are not mandatory. The original list of signatures corresponds to every non-mandatory statement and the indexes of these in the original document are given above. We now compute a list of adjusted signature indexes by computing the index of each selective index in the non-mandatory index list, ignoring any selective index not present in the list. We then use the adjusted signature indexes to obtain the filtered signature list. These lists are shown below.

The last important piece of disclosure data is a mapping of canonical blank node ids to HMAC based ids, the `labelMap`, computed according to [[[VC-DATA-INTEGRITY-1.1#CreateDisclosureData]]]. This is shown below along with the rest of the disclosure data minus the reveal document.

Finally using the disclosure data above with the algorithm of Section [[[VC-DATA-INTEGRITY-1.1#SerializeDerived-SIC]]] we obtain the signed derived (reveal) document shown below.

Base Proof

In order to add a selective disclosure base proof to a document the issuer needs the following cryptographic key material:

1. The issuers private/public key pair, i.e., the key pair corresponding to the verification method that will be part of the proof.
2. A per proof private/public key pair created by the issuer just for this proof. This is an ephemeral, single use key pair where the private key is not kept after the proof has been generated.
3. An HMAC key. This used to randomize the order of the blank node ids to avoid potential information leakage from the blank node id ordering. This is used only once and is shared between issuer and holder. The HMAC in this case is functioning as a pseudorandom function (PRF).

The key material used for generating the add base proof test vectors is shown below. Multibase representation is use for the P-256 key pairs and the HMAC key is given as a hexadecimal string.

In our scenario a person will be issued a permanent resident credential as shown below.

The mandatory information as specified by the issuer is specified via an array of JSON pointers as shown below.

The result of applying the above JSON pointers to the permanent resident credential is shown below.

Transformation of the unsigned document begins with canonicalizing the document as shown below.

To prevent possible information leakage from the ordering of the blank node ids these are processed through a PRF, i.e., the HMAC to give the canonized HMAC document shown below. This represents an ordered list of statements that will be subject to mandatory and selective disclosure, i.e., it is from this list that statements are grouped.

The above canonical document gets grouped in to mandatory and non-mandatory statements. The final output of the selective disclosure transformation process is shown below. Each statement is now grouped as mandatory and non-mandatory and its index in the previous list of statements is remembered.

The next step is to create the base proof configuration and canonicalize it. This is shown in the following two examples.

In the hashing step we compute the SHA-256 hash of the canonicalized proof options to produce the `proofHash` and we compute the SHA-256 hash of the join of all the mandatory nquads to produce the `mandatoryHash`. These are shown below in hexadecimal format.

We compute the `baseSignature` over the concatenation of the `proofHash`, `proofPublicKey`, and `mandatoryHash` using the issuers long term `privateKey`. We compute the `signatures` array by signing each non-mandatory nquad using the per `proofPrivateKey`. These signatures, the `proofPublicKey`, and `mandatoryPointers` which are fed to the final serialization step are shown below.

Finally, the values above are run through the algorithm of Section [[[VC-DATA-INTEGRITY-1.1#SerializeBase-SIC]]] to produce the `proofValue` which is used in the signed based document shown below.

Derived Proof

In order to create a derived proof a holder starts with a signed document containing a base proof. The base document we will use for these test vectors is the final example from Section [[[#base-proof]]] above. The first step is to run the algorithm of [[[VC-DATA-INTEGRITY-1.1#ParseBase-SIC]]] to recover `baseSignature`, `publicKey`, `hmacKey`, `signatures`, and `mandatoryPointers` as shown below.

Next, the holder needs to indicate what, if anything else, they wish to reveal to the verifiers by specifying JSON pointers for selective disclosure.

To produce the `revealDocument`, i.e., the unsigned document that will eventually be signed and sent to the verifier, we append the selective pointers to the mandatory pointers and input these combined pointers along with the document without proof to the algorithm of [[[VC-DATA-INTEGRITY-1.1#selectjsonld]]] to give the result shown below.

Now that we know what the revealed document looks like, we need to furnish appropriately updated information to the verifier on which statements are mandatory, the signatures for the selected non-mandatory statements, and the mapping between canonical blank node ids for the reveal document and a subset of the HMAC blank node ids. Running [[[VC-DATA-INTEGRITY-1.1#CreateDisclosureData]]] yields an abundance of information about various statement groups relative to the original document. Below we show a portion of the indexes for those groups.

The verifier needs to be able to aggregate and hash the mandatory statements. To enable this we furnish them with a list of indexes of the mandatory statements adjusted to their positions in the reveal document. In the previous example the `combinedIndexes` show the indexes of all the original nquads (statements) that make up the reveal document, in order. To come up with the adjusted mandatory indexes shown below we obtain the index of each of original mandatory indexes relative to the `combinedIndexes` as shown below.

We have to furnish the verifier with a list of signatures for those selective statements (nquads) that are not mandatory. The original list of signatures corresponds to every non-mandatory statement and the indexes of these in the original document are given above. We now compute a list of adjusted signature indexes by computing the index of each selective index in the non-mandatory index list, ignoring any selective index not present in the list. We then use the adjusted signature indexes to obtain the filtered signature list. These lists are shown below.

The last important piece of disclosure data is a mapping of canonical blank node ids to HMAC based ids, the `labelMap`, computed according to Section [[[VC-DATA-INTEGRITY-1.1#CreateDisclosureData]]]. This is shown below along with the rest of the disclosure data minus the reveal document.

Finally using the disclosure data above with the algorithm of Section [[[VC-DATA-INTEGRITY-1.1#SerializeDerived-SIC]]] we obtain the signed derived (reveal) document shown below.