This specification describes the BBS+ Signature Suite created in 2020 for the Linked Data Proof specification. The Signature Suite utilizes BBS+ signatures to provide the capability of zero knowledge proof disclosures.

This is an experimental specification and is undergoing regular revisions. It is not fit for production deployment.

This specification defines a set of cryptographic suites for the purpose of creating, verifying and deriving proofs for BBS+ Signatures in conformance with the Linked Data Proofs [[LD-PROOFS]] specification.

In general the suites uses the RDF Dataset Normalization Algorithm [[RDF-DATASET-NORMALIZATION]] to transform an input document into its canonical form. It then uses the statement digest algorithm to digest each statement to be signed individually, finally the digested statements are signed using the defined signature algorithm.

BBS+ signatures [[BBS]] are compatible with any pairing friendly elliptic curve, however the cryptographic suites defined in this document elect to only allow the usage of the BLS12-381 for interoperability purposes.

The following terms are used to describe concepts involved in the generation and verification of the Linked Data Proof signature suite.

- signature suite
- A specified set of cryptographic primitives typically consisting of a canonicalization algorithm, a message digest algorithm, and a signature algorithm that are bundled together by cryptographers for developers for the purposes of safety and convenience.
- canonicalization algorithm
- An algorithm that takes an input document that has more than one possible representation and always transforms it into a canonical form. This process is sometimes also called normalization.
- canonical form
- The output of applying a canonicalization algorithm to an input document.
- statement
- n-quads statements are a sequence of RDF terms representing the subject, predicate, object and graph label. See the grammar definition here.
- statement digest algorithm
- An algorithm that takes a statement and produces a cryptographic output message that is often many orders of magnitude smaller than the input message. These algorithms are often 1) very fast, 2) non-reversible, 3) cause the output to change significantly when even one bit of the input message changes, and 4) make it infeasible to find two different inputs for the same output.
- statement digest
- The result of the application of the statement digest algorithm to a statement
- signature algorithm
- An algorithm that takes an input message and produces an output value where the receiver of the message can mathematically verify that the message has not been modified in transit and came from someone possessing a particular secret.
- selective disclosure
- An information disclosure technique which is the process of deciding and disclosing a sub-set of information from an original information set.
- linked data proof document
- A linked data document featuring one or more linked data proofs.
- revealed statements
- The set of statements produced by applying the canonicalization algorithm to the reveal document.
- derive proof algorithm
- An algorithm that takes in a linked data proof document featuring a linked data proof that supports a derive proof algorithm along side a reveal document and derives a proof only revealing the statements defined in the reveal document.
- derived proof
- The product of apply the derive proof algorithm to an linked data proof document and reveal document.
- quad
- A quad as specified by [[RDF-DATASET-NORMALIZATION]]
- n-quad
- An n-quad which is a line based, plain text format encoding of a quad as defined by [[RDF-N-Quads]].
- linked data proof
- A linked data proof which is a set of attributes that represent a linked data digital proof and the parameters required to verify it as defined by [[RDF-N-Quads]].
- linked data document
- A document comprised of linked data.
- curve name
- The name defining a particular cryptographic curve.
- frame
- A frame as specified by [[JSON-LD-FRAMING]] is a JSON-LD document, which describes the form for transforming another JSON-LD document using matching and embedding rules. A frame document allows additional keywords and certain map entries to describe the matching and transforming process.
- JSON-LD document
- A JSON-LD document as specified by [[JSON-LD-FRAMING]] is a is a serialization of an RDF dataset
- framing algorithm
- A Framing Algorithm as specified by [[JSON-LD-FRAMING]] is an algorithm that accomplishes the process of framing an input document to a given frame.
- blank node
- A blank node as specified by [[RDF-CONCEPTS]]. In short, it is a node in a graph that is neither an IRI, nor a literal.

Defined in [[PAIRING-FRIENDLY-CURVES]], BLS12-381 is an elliptic curve that features a unique property only present in a subset of elliptic curves known as being pairing friendly.

Because of the pairing friendly property, BLS12-381 can be used to construct digital signatures that have unique properties, such as aggregatable signatures and or signatures that support zero knowledge proof disclosure.

TODO: Is the the below the correct place for the rationale?

With pairing friendly elliptic curves, there are two fields, denoted G1 and G2, for which signatures and public keys can exist. Importantly however both the public key and a signature generated using the public key cannot exist in the same field.

Due to the properties of the two fields, there are different associated performance characteristics to selecting which field to use for signatures vs which field to use for public key generation. In general operations are faster in G1 and the resulting commitments are smaller. With this definition of BBS+ signatures we have opted for signatures to be faster and smaller to create rather than key generation.

The keys definition MUST have an attribute of `publicKeyBase58`

and its value
MUST be a base58 encoded BLS12-381 public key in the G2 field. Where the
BLS12-381 public key is the concatenation of the 2 raw 48 byte x co-ordinates
defining the commitment.

A simple example of a Bls12381G2Key2020:

{ "id": "did:example:123456789abcdefghi#keys-1", "type": "Bls12381G2Key2020", "controller": "did:example:123456789abcdefghi", "publicKeyBase58" : "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" }

The BBS+ signature suite 2020 MUST be used in conjunction with the signing and verification algorithms in the Linked Data Proofs [[LD-PROOFS]] specification. The suite consists of the following algorithms:

Parameter | Value | Specification |
---|---|---|

canonicalization algorithm | https://w3id.org/security#URDNA2015 | [[RDF-DATASET-NORMALIZATION]] |

statement digest algorithm | SHAKE-256 | [[SHA-3]] |

signature algorithm | BBS+ Signature | [[BBS]] |

curve name | BLS12-381 | [[PAIRING-FRIENDLY-CURVES]] |

In order to support selective disclosure of statements, the create verify data algorithm has been modified from its original definition.

The algorithm defined below, outlines the process of obtaining the data in the form required for both signing and verifying.

- Canonicalize the input document using the canonicalization algorithm to a set of statements represented as n-quads.
- Initialize an empty array of length equal to the number of statements, let this be known as the statement digests array.
- For each statement in order:
- Apply the statement digest algorithm to obtain a statement digest
- Insert the statement digest into the statement digests array which MUST maintain same order as the order of the statements returned from the canonicalization algorithm.

- Returned the statement digests array.

The following section outlines the terms used by the BBS+ Signature Suite.

To identify the type of linked data proof that is attached to a linked data document,
the `type`

attribute defined in
[[LD-PROOFS]].

The term of `BbsSignature2020`

is used to indicate when a linked data proof is of type BBS+ Signature.

A linked data document featuring a BBS+ Signature linked data proof
MUST contain a proof element thats has a type equal to `BbsSignature2020`

.

```
{
"@context": [
"http://schema.org/",
"https://w3id.org/security/v2",
"https://w3c-ccg.github.io/lds-bbsbls2020/contexts"
],
"@type": "Person",
"firstName": "Jane",
"lastName": "Does",
"jobTitle": "Professor",
"telephone": "(425) 123-4567",
"email": "jane.doe@example.com",
"proof": {
"type": "BbsBlsSignature2020",
"created": "2020-04-25",
"verificationMethod": "did:example:489398593#test",
"proofPurpose": "assertionMethod",
"requiredRevealStatements": [ 4, 5 ],
"signature": "F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg=="
}
}
```

When a digital signature is produced, it is often useful to capture when this occurred, the `created`

attribute
can be used to communicate this as defined in
[[LD-PROOFS]].

A linked data document featuring a BBS+ Signature linked data proof MAY contain a `created`

attribute with value a value corresponding to an [[!ISO8601]] combined date and time string.

```
{
"@context": [
"http://schema.org/",
"https://w3id.org/security/v2",
"https://w3c-ccg.github.io/lds-bbsbls2020/contexts"
],
"@type": "Person",
"firstName": "Jane",
"lastName": "Does",
"jobTitle": "Professor",
"telephone": "(425) 123-4567",
"email": "jane.doe@example.com",
"proof": {
"type": "BbsBlsSignature2020",
"created": "2020-04-25",
"verificationMethod": "did:example:489398593#test",
"proofPurpose": "assertionMethod",
"requiredRevealStatements": [ 4, 5 ],
"signature": "F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg=="
}
}
```

When verifying a digital signature, public key material of the signer is required, the `verificationMethod`

attribute is
used to communicate this as defined in [[LD-PROOFS]].

A linked data document featuring a BBS+ Signature linked data proof MUST contain a `verificationMethod`

attribute with a value that is either the verification method required to verify the linked data proof or a URI that when dereferenced
results in the verification method required to verify the linked data proof.

The verification method MUST be of `type`

Bls12381G2Key2020.

```
{
"@context": [
"http://schema.org/",
"https://w3id.org/security/v2",
"https://w3c-ccg.github.io/lds-bbsbls2020/contexts"
],
"@type": "Person",
"firstName": "Jane",
"lastName": "Does",
"jobTitle": "Professor",
"telephone": "(425) 123-4567",
"email": "jane.doe@example.com",
"proof": {
"type": "BbsBlsSignature2020",
"created": "2020-04-25",
"verificationMethod": "did:example:489398593#test",
"proofPurpose": "assertionMethod",
"requiredRevealStatements": [ 4, 5 ],
"signature": "F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg=="
}
}
```

A proof purpose defines what the purpose of the created proof was and is used to detect whether the verification method has been used correctly.

A linked data document featuring a BBS+ Signature linked data proof MUST contain a `proofPurpose`

attribute with a value that is defined in [[LD-PROOFS]].

```
{
"@context": [
"http://schema.org/",
"https://w3id.org/security/v2",
"https://w3c-ccg.github.io/lds-bbsbls2020/contexts"
],
"@type": "Person",
"firstName": "Jane",
"lastName": "Does",
"jobTitle": "Professor",
"telephone": "(425) 123-4567",
"email": "jane.doe@example.com",
"proof": {
"type": "BbsBlsSignature2020",
"created": "2020-04-25",
"verificationMethod": "did:example:489398593#test",
"proofPurpose": "assertionMethod",
"requiredRevealStatements": [ 4, 5 ],
"signature": "F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg=="
}
}
```

When producing a digital signature that is capable of selective disclosure with a set signed statements, it is useful for the signer to be able to express as apart of the proof which statements must be revealed in a derived proof

A linked data document featuring a BBS+ Signature linked data proof MUST contain a `requiredRevealStatements`

attribute with a value that is an array of un-signed integers representing the indicies of the statements in the canonical form
that MUST always be revealed in a derived proof. The indicies corresponding to the statements for the `verificationMethod`

and `proofPurpose`

as apart of the linked data proof MUST always be present.

```
{
"@context": [
"http://schema.org/",
"https://w3id.org/security/v2",
"https://w3c-ccg.github.io/lds-bbsbls2020/contexts"
],
"@type": "Person",
"firstName": "Jane",
"lastName": "Does",
"jobTitle": "Professor",
"telephone": "(425) 123-4567",
"email": "jane.doe@example.com",
"proof": {
"type": "BbsBlsSignature2020",
"created": "2020-04-25",
"verificationMethod": "did:example:489398593#test",
"proofPurpose": "assertionMethod",
"requiredRevealStatements": [ 4, 5 ],
"signature": "F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg=="
}
}
```

The raw signature value outputted by computing a sign operation must feature in the proof, in order for parties to verify the signature.

A linked data document featuring a BBS+ Signature linked data proof MUST contain a `signature`

attribute with value defined by the signing algorithm described in this specification.

TODO: Define the encoding scheme for the signature value

```
{
"@context": [
"http://schema.org/",
"https://w3id.org/security/v2",
"https://w3c-ccg.github.io/lds-bbsbls2020/contexts"
],
"@type": "Person",
"firstName": "Jane",
"lastName": "Does",
"jobTitle": "Professor",
"telephone": "(425) 123-4567",
"email": "jane.doe@example.com",
"proof": {
"type": "BbsBlsSignature2020",
"created": "2020-04-25",
"verificationMethod": "did:example:489398593#test",
"proofPurpose": "assertionMethod",
"requiredRevealStatements": [ 4, 5 ],
"signature": "F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg=="
}
}
```

A BBS proof of knowledge linked data proof is a proof that is derived from a BBSSignature2020 linked data proof where by a sub-set of the original statements are revealed.

The BBS+ proof of knowledge signature suite MUST be used in conjunction with the signing and verification algorithms in the Linked Data Proofs [[LD-PROOFS]] specification. The suite consists of the following algorithms:

Parameter | Value | Specification |
---|---|---|

canonicalization algorithm | https://w3id.org/security#URDNA2015 | [[RDF-DATASET-NORMALIZATION]] |

statement digest algorithm | SHAKE-256 | [[SHA-3]] |

signature algorithm | BBS+ Signature | [[BBS]] |

curve name | BLS12-381 | [[PAIRING-FRIENDLY-CURVES]] |

The following section outlines the terms used by the BBS+ proof of knowledge signature suite.

To identify the type of linked data proof that is attached to a linked data document,
the `type`

attribute is used as defined in
[[LD-PROOFS]].

The term of `BbsSignatureProof2020`

is used to indicate when a linked data proof is of type BBS+ proof of knowledge.

A linked data document featuring a BBS+ proof of knowledge linked data proof
MUST contain a `type`

attribute thats has a type equal to `BbsSignatureProof2020`

.

```
{
"@context": [
"http://schema.org/",
"https://w3id.org/security/v2",
"https://w3c-ccg.github.io/lds-bbsbls2020/contexts"
],
"id": "urn:bnid:_:c14n0",
"email": "jane.doe@example.com",
"firstName": "Jane",
"jobTitle": "Professor",
"lastName": "Does",
"telephone": "(425) 123-4567",
"proof": {
"type": "BbsBlsSignatureProof2020",
"created": "2020-04-25",
"verificationMethod": "did:example:489398593#test",
"proofPurpose": "assertionMethod",
"proofValue": "kTTbA3pmDa6Qia/JkOnIXDLmoBz3vsi7L5t3DWySI/VLmBqleJ/Tbus5RoyiDERDBEh5rnACXlnOqJ/U8yFQFtcp/mBCc2FtKNPHae9jKIv1dm9K9QK1F3GI1AwyGoUfjLWrkGDObO1ouNAhpEd0+et+qiOf2j8p3MTTtRRx4Hgjcl0jXCq7C7R5/nLpgimHAAAAdAx4ouhMk7v9dXijCIMaG0deicn6fLoq3GcNHuH5X1j22LU/hDu7vvPnk/6JLkZ1xQAAAAIPd1tu598L/K3NSy0zOy6obaojEnaqc1R5Ih/6ZZgfEln2a6tuUp4wePExI1DGHqwj3j2lKg31a/6bSs7SMecHBQdgIYHnBmCYGNQnu/LZ9TFV56tBXY6YOWZgFzgLDrApnrFpixEACM9rwrJ5ORtxAAAAAgE4gUIIC9aHyJNa5TBklMOh6lvQkMVLXa/vEl+3NCLXblxjgpM7UEMqBkE9/QcoD3Tgmy+z0hN+4eky1RnJsEg=",
"nonce": "6i3dTz5yFfWJ8zgsamuyZa4yAHPm75tUOOXddR6krCvCYk77sbCOuEVcdBCDd/l6tIY="
}
}
```

TODO: Add paragraph?

A linked data document featuring a BBS+ Signature linked data proof MAY contain a `created`

attribute with value a value corresponding to an [[!ISO8601]] combined date and time string.

```
{
"@context": [
"http://schema.org/",
"https://w3id.org/security/v2",
"https://w3c-ccg.github.io/lds-bbsbls2020/contexts"
],
"id": "urn:bnid:_:c14n0",
"email": "jane.doe@example.com",
"firstName": "Jane",
"jobTitle": "Professor",
"lastName": "Does",
"telephone": "(425) 123-4567",
"proof": {
"type": "BbsBlsSignatureProof2020",
"created": "2020-04-25",
"verificationMethod": "did:example:489398593#test",
"proofPurpose": "assertionMethod",
"proofValue": "kTTbA3pmDa6Qia/JkOnIXDLmoBz3vsi7L5t3DWySI/VLmBqleJ/Tbus5RoyiDERDBEh5rnACXlnOqJ/U8yFQFtcp/mBCc2FtKNPHae9jKIv1dm9K9QK1F3GI1AwyGoUfjLWrkGDObO1ouNAhpEd0+et+qiOf2j8p3MTTtRRx4Hgjcl0jXCq7C7R5/nLpgimHAAAAdAx4ouhMk7v9dXijCIMaG0deicn6fLoq3GcNHuH5X1j22LU/hDu7vvPnk/6JLkZ1xQAAAAIPd1tu598L/K3NSy0zOy6obaojEnaqc1R5Ih/6ZZgfEln2a6tuUp4wePExI1DGHqwj3j2lKg31a/6bSs7SMecHBQdgIYHnBmCYGNQnu/LZ9TFV56tBXY6YOWZgFzgLDrApnrFpixEACM9rwrJ5ORtxAAAAAgE4gUIIC9aHyJNa5TBklMOh6lvQkMVLXa/vEl+3NCLXblxjgpM7UEMqBkE9/QcoD3Tgmy+z0hN+4eky1RnJsEg=",
"nonce": "6i3dTz5yFfWJ8zgsamuyZa4yAHPm75tUOOXddR6krCvCYk77sbCOuEVcdBCDd/l6tIY="
}
}
```

A linked data document featuring a BBS+ proof of knowledge linked data proof MUST contain a `verificationMethod`

attribute with a value that is equal to that of the BBSSignature2020 for which the proof is derived from.

TODO: Add paragraph?

```
{
"@context": [
"http://schema.org/",
"https://w3id.org/security/v2",
"https://w3c-ccg.github.io/lds-bbsbls2020/contexts"
],
"id": "urn:bnid:_:c14n0",
"email": "jane.doe@example.com",
"firstName": "Jane",
"jobTitle": "Professor",
"lastName": "Does",
"telephone": "(425) 123-4567",
"proof": {
"type": "BbsBlsSignatureProof2020",
"created": "2020-04-25",
"verificationMethod": "did:example:489398593#test",
"proofPurpose": "assertionMethod",
"proofValue": "kTTbA3pmDa6Qia/JkOnIXDLmoBz3vsi7L5t3DWySI/VLmBqleJ/Tbus5RoyiDERDBEh5rnACXlnOqJ/U8yFQFtcp/mBCc2FtKNPHae9jKIv1dm9K9QK1F3GI1AwyGoUfjLWrkGDObO1ouNAhpEd0+et+qiOf2j8p3MTTtRRx4Hgjcl0jXCq7C7R5/nLpgimHAAAAdAx4ouhMk7v9dXijCIMaG0deicn6fLoq3GcNHuH5X1j22LU/hDu7vvPnk/6JLkZ1xQAAAAIPd1tu598L/K3NSy0zOy6obaojEnaqc1R5Ih/6ZZgfEln2a6tuUp4wePExI1DGHqwj3j2lKg31a/6bSs7SMecHBQdgIYHnBmCYGNQnu/LZ9TFV56tBXY6YOWZgFzgLDrApnrFpixEACM9rwrJ5ORtxAAAAAgE4gUIIC9aHyJNa5TBklMOh6lvQkMVLXa/vEl+3NCLXblxjgpM7UEMqBkE9/QcoD3Tgmy+z0hN+4eky1RnJsEg=",
"nonce": "6i3dTz5yFfWJ8zgsamuyZa4yAHPm75tUOOXddR6krCvCYk77sbCOuEVcdBCDd/l6tIY="
}
}
```

TODO: Add paragraph?

A linked data document featuring a BBS+ proof of knowledge linked data proof MUST contain a `proofPurpose`

attribute with a value that is equal to that of the BBSSignature2020 for which the proof is derived from.

```
{
"@context": [
"http://schema.org/",
"https://w3id.org/security/v2",
"https://w3c-ccg.github.io/lds-bbsbls2020/contexts"
],
"id": "urn:bnid:_:c14n0",
"email": "jane.doe@example.com",
"firstName": "Jane",
"jobTitle": "Professor",
"lastName": "Does",
"telephone": "(425) 123-4567",
"proof": {
"type": "BbsBlsSignatureProof2020",
"created": "2020-04-25",
"verificationMethod": "did:example:489398593#test",
"proofPurpose": "assertionMethod",
"proofValue": "kTTbA3pmDa6Qia/JkOnIXDLmoBz3vsi7L5t3DWySI/VLmBqleJ/Tbus5RoyiDERDBEh5rnACXlnOqJ/U8yFQFtcp/mBCc2FtKNPHae9jKIv1dm9K9QK1F3GI1AwyGoUfjLWrkGDObO1ouNAhpEd0+et+qiOf2j8p3MTTtRRx4Hgjcl0jXCq7C7R5/nLpgimHAAAAdAx4ouhMk7v9dXijCIMaG0deicn6fLoq3GcNHuH5X1j22LU/hDu7vvPnk/6JLkZ1xQAAAAIPd1tu598L/K3NSy0zOy6obaojEnaqc1R5Ih/6ZZgfEln2a6tuUp4wePExI1DGHqwj3j2lKg31a/6bSs7SMecHBQdgIYHnBmCYGNQnu/LZ9TFV56tBXY6YOWZgFzgLDrApnrFpixEACM9rwrJ5ORtxAAAAAgE4gUIIC9aHyJNa5TBklMOh6lvQkMVLXa/vEl+3NCLXblxjgpM7UEMqBkE9/QcoD3Tgmy+z0hN+4eky1RnJsEg=",
"nonce": "6i3dTz5yFfWJ8zgsamuyZa4yAHPm75tUOOXddR6krCvCYk77sbCOuEVcdBCDd/l6tIY="
}
}
```

The raw value outputted by computing a derive proof operation must feature in the proof, in order for parties to be able to verify the proof.

A linked data document featuring a BBS+ proof of knowledge linked data proof
MUST contain a `proof`

attribute with value defined by the derive proof algorithm
described in this specification.

```
{
"@context": [
"http://schema.org/",
"https://w3id.org/security/v2",
"https://w3c-ccg.github.io/lds-bbsbls2020/contexts"
],
"id": "urn:bnid:_:c14n0",
"email": "jane.doe@example.com",
"firstName": "Jane",
"jobTitle": "Professor",
"lastName": "Does",
"telephone": "(425) 123-4567",
"proof": {
"type": "BbsBlsSignatureProof2020",
"created": "2020-04-25",
"verificationMethod": "did:example:489398593#test",
"proofPurpose": "assertionMethod",
"proofValue": "kTTbA3pmDa6Qia/JkOnIXDLmoBz3vsi7L5t3DWySI/VLmBqleJ/Tbus5RoyiDERDBEh5rnACXlnOqJ/U8yFQFtcp/mBCc2FtKNPHae9jKIv1dm9K9QK1F3GI1AwyGoUfjLWrkGDObO1ouNAhpEd0+et+qiOf2j8p3MTTtRRx4Hgjcl0jXCq7C7R5/nLpgimHAAAAdAx4ouhMk7v9dXijCIMaG0deicn6fLoq3GcNHuH5X1j22LU/hDu7vvPnk/6JLkZ1xQAAAAIPd1tu598L/K3NSy0zOy6obaojEnaqc1R5Ih/6ZZgfEln2a6tuUp4wePExI1DGHqwj3j2lKg31a/6bSs7SMecHBQdgIYHnBmCYGNQnu/LZ9TFV56tBXY6YOWZgFzgLDrApnrFpixEACM9rwrJ5ORtxAAAAAgE4gUIIC9aHyJNa5TBklMOh6lvQkMVLXa/vEl+3NCLXblxjgpM7UEMqBkE9/QcoD3Tgmy+z0hN+4eky1RnJsEg=",
"nonce": "6i3dTz5yFfWJ8zgsamuyZa4yAHPm75tUOOXddR6krCvCYk77sbCOuEVcdBCDd/l6tIY="
}
}
```

When a proof is derived it is often useful to prove to the audience of the proof the uniqueness or freshness of proof, the nonce attribute can be used to communicate this.

A linked data document featuring a BBS+ proof of knowledge linked data proof
MAY contain a `nonce`

attribute.

```
{
"@context": [
"http://schema.org/",
"https://w3id.org/security/v2",
"https://w3c-ccg.github.io/lds-bbsbls2020/contexts"
],
"id": "urn:bnid:_:c14n0",
"email": "jane.doe@example.com",
"firstName": "Jane",
"jobTitle": "Professor",
"lastName": "Does",
"telephone": "(425) 123-4567",
"proof": {
"type": "BbsBlsSignatureProof2020",
"created": "2020-04-25",
"verificationMethod": "did:example:489398593#test",
"proofPurpose": "assertionMethod",
"proof": "kTTbA3pmDa6Qia/JkOnIXDLmoBz3vsi7L5t3DWySI/VLmBqleJ/Tbus5RoyiDERDBEh5rnACXlnOqJ/U8yFQFtcp/mBCc2FtKNPHae9jKIv1dm9K9QK1F3GI1AwyGoUfjLWrkGDObO1ouNAhpEd0+et+qiOf2j8p3MTTtRRx4Hgjcl0jXCq7C7R5/nLpgimHAAAAdAx4ouhMk7v9dXijCIMaG0deicn6fLoq3GcNHuH5X1j22LU/hDu7vvPnk/6JLkZ1xQAAAAIPd1tu598L/K3NSy0zOy6obaojEnaqc1R5Ih/6ZZgfEln2a6tuUp4wePExI1DGHqwj3j2lKg31a/6bSs7SMecHBQdgIYHnBmCYGNQnu/LZ9TFV56tBXY6YOWZgFzgLDrApnrFpixEACM9rwrJ5ORtxAAAAAgE4gUIIC9aHyJNa5TBklMOh6lvQkMVLXa/vEl+3NCLXblxjgpM7UEMqBkE9/QcoD3Tgmy+z0hN+4eky1RnJsEg=",
"nonce": "6i3dTz5yFfWJ8zgsamuyZa4yAHPm75tUOOXddR6krCvCYk77sbCOuEVcdBCDd/l6tIY="
}
}
```

In order to support selective disclosure of statements, the following derive proof algorithm has been defined.

TODO: Add examples and full definition of this algorithm

The following algorithm defined below outlines the process of obtaining the inputs into the derive proof algorithm.

- Apply the canonicalization algorithm to the input proof document to obtain a set of statements represented as n-quads. Let this set be known as the input proof document statements.
- Record the total number of statements in the input proof document statements. Let this be known as the total statements.
- Apply the framing algorithm to the input proof document. Let the product of the framing algorithm be known as the revealed document.
- Canonicalize the revealed document using the canonicalization algorithm to obtain the set of statements represented as n-quads. Let these be known as the revealed statements.
- Initialize an empty array of length equal to the number of revealed statements. Let this be known as the revealed indicies array.
- For each statement in order:
- Find the numerical index the statement occupies in the set input proof document statements.
- Insert this numerical index into the revealed indicies array

- Returned the revealed indicies array, total statements and input proof document statements.

TODO: Define how we have to validate the requiredRevealStatements

TODO: Add a comment on how we diff the input proof document and the reveal
document to produce get the correct node identifiers for the reveal document

TODO: Add paragraph

The following section describes security considerations that developers implementing this specification should be aware of in order to create secure software.

TODO: We need to add a complete list of security
considerations.