BBS Cryptosuite v2023

Achieving Data Integrity using Unlinkable BBS Signatures

Final Community Group Report

This version:
https://www.w3.org/community/reports/credentials/CG-FINAL-vc-di-bbs-20230412/
Latest published version:
https://www.w3.org/community/reports/credentials/CG-FINAL-vc-di-bbs-20230405/
Latest editor's draft:
https://w3c-ccg.github.io/vc-di-bbs/
Editors:
Tobias Looker (Mattr)
Orie Steele (Transmute)
Feedback:
public-credentials@w3.org with subject line [vc-di-bbs] … message topic … (archives)

Copyright © 2023 the Contributors to the BBS Cryptosuite v2023 Specification, published by the Credentials Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available.

Abstract

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

Status of This Document

This specification was published by the Credentials Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Final Specification Agreement (FSA) other conditions apply. Learn more about W3C Community and Business Groups.

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

If you wish to make comments regarding this document, please send them to public-credentials@w3.org (subscribe, archives).

1. Introduction

This specification defines a set of cryptographic suites for the purpose of creating, verifying and deriving proofs for BBS+ Signatures in conformance with the Data Integrity [DATA-INTEGRITY] 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.

1.1 Terminology

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

This section defines the terms used in this specification. A link to these terms is included whenever they appear in this specification.

data integrity proof
A set of attributes that represent a digital proof and the parameters required to verify it.
private key
Cryptographic material that can be used to generate digital proofs.
challenge
A random or pseudo-random value used by some authentication protocols to mitigate replay attacks.
domain
A string value that specifies the operational domain of a digital proof. This could be an Internet domain name like example.com, an ad-hoc value such as mycorp-level3-access, or a very specific transaction value like 8zF6T8J34qP3mqP. A signer could include a domain in its digital proof to restrict its use to particular target, identified by the specified domain.
cryptographic suite
A specification defining the usage of specific cryptographic primitives in order to achieve a particular security goal. These documents are often used to specify verification methods, digital signature types, their identifiers, and other related properties.
decentralized identifier (DID)
A globally unique persistent identifier that does not require a centralized registration authority and is often generated and/or registered cryptographically. The generic format of a is defined in [DID-CORE]. Many—but not all—methods make use of distributed ledger technology (DLT) or some other form of decentralized network.
controller
An entity that has the capability to make changes to a controller document.
controller document
A set of data that specifies one or more relationships between a controller and a set of data, such as a set of public cryptographic keys.
subject
The entity identified by the id property in a controller document. Anything can be a subject: person, group, organization, physical thing, digital thing, logical thing, etc.
distributed ledger (DLT)
A non-centralized system for recording events. These systems establish sufficient confidence for participants to rely upon the data recorded by others to make operational decisions. They typically use distributed databases where different nodes use a consensus protocol to confirm the ordering of cryptographically signed transactions. The linking of digitally signed transactions over time often makes the history of the ledger effectively immutable.
verification method

A set of parameters that can be used together with a process to independently verify a proof. For example, a cryptographic public key can be used as a verification method with respect to a digital signature; in such usage, it verifies that the signer possessed the associated cryptographic private key.

"Verification" and "proof" in this definition are intended to apply broadly. For example, a cryptographic public key might be used during Diffie-Hellman key exchange to negotiate a shared symmetric key for encryption. This guarantees the integrity of the key agreement process. It is thus another type of verification method, even though descriptions of the process might not use the words "verification" or "proof."

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.
data integrity proof document
A linked data document featuring one or more data integrity 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 data integrity proof document featuring a data integrity 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 data integrity 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 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.

1.2 Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, and RECOMMENDED in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Issue 1
TODO: Add paragraph

2. Data Model

The following sections outline the data model that is used by this specification for verification methods and data integrity proof formats.

2.1 Verification Methods

The cryptographic material used to verify a data integrity proof is called the verification method. This suite relies on public key material represented using [MULTIBASE], [MULTICODEC], and JSON Web Key [RFC7517].

This suite MAY be used to verify Data Integrity Proofs [VC-DATA-INTEGRITY] produced by BLS12-381 public key material encoded as a Multikey. Loss-less key transformation processes that result in equivalent cryptographic material MAY be utilized.

2.1.1 Multikey

Issue 2

This definition should go in the Data Integrity specification and referenced from there.

The type of the verification method MUST be Multikey.

The controller of the verification method MUST be a URL.

The publicKeyMultibase property of the verification method MUST be a public key encoded according to [MULTICODEC] and formatted according to [MULTIBASE]. The multicodec encoding of a BLS12-381 public key that combines both the G1 and G2 fields is the byte prefix 0xee followed by the 48-byte G1 public key data, which is then followed by the 96-byte G2 public key data. The 145 byte value is then encoded using base64url with no padding (u) as the prefix. Any other encodings MUST NOT be allowed.

Developers are advised to not accidentally publish a representation of a private key. Implementations of this specification will raise errors in the event of a [MULTICODEC] value other than 0xee being used in a publicKeyMultibase value.

Example 1: An BLS12-381 public key containing the G1 and G2 values, encoded as a Multikey 
{
  "id": "https://example.com/issuer/123#key-0",
  "type": "Multikey",
  "controller": "https://example.com/issuer/123",
  "publicKeyMultibase": "u7ljnAxKdp7YVqJvcMU9GtnmrMc1XZztXHsTsZ2LsmGJ67SsdbmNc
    S2SDs0daEPfhVXgODk0IVrgguJ-TJACHyXYa9Ae8DaxcvRy89KLgmWsyOOJn2oY7vCE2gt
    JoebMJiQsdbmNcS2SDs0daEPfhVXgODk0IVrgguJ-TJACHyXYa9Ae8DaxcvRy89KLgm"
}
Example 2: A BLS12-381 public key containing the G1 and G2 values, encoded as a Multikey in a controller document 
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/data-integrity/v1"
  ],
  "id": "did:example:123",
  "verificationMethod": [{
    "id": "https://example.com/issuer/123#key-1",
    "type": "Multikey",
    "controller": "https://example.com/issuer/123",
    "publicKeyMultibase": "zDnaerx9CtbPJ1q36T5Ln5wYt3MQYeGRG5ehnPAmxcf5mDZpv"
  }, {
    "id": "https://example.com/issuer/123#key-2",
    "type": "Multikey",
    "controller": "https://example.com/issuer/123",
    "publicKeyMultibase": "u7ljnAxKdp7YVqJvcMU9GtnmrMc1XZztXHsTsZ2LsmGJ67SsdbmNc
      S2SDs0daEPfhVXgODk0IVrgguJ-TJACHyXYa9Ae8DaxcvRy89KLgmWsyOOJn2oY7vCE2gt
      JoebMJiQsdbmNcS2SDs0daEPfhVXgODk0IVrgguJ-TJACHyXYa9Ae8DaxcvRy89KLgm"
  }],
  "authentication": [
    "did:example:123#key-1"
  ],
  "assertionMethod": [
    "did:example:123#key-2"
  ],
  "capabilityDelegation": [
    "did:example:123#key-1"
  ],
  "capabilityInvocation": [
    "did:example:123#key-1"
  ]
}

2.1.2 JsonWebKey

Issue 3

This definition should go in the Data Integrity specification and referenced from there.

The type of the verification method MUST be JsonWebKey.

The controller of the verification method MUST be a URL.

The publicKeyJwk property of the verification method MUST be a public key encoded according to [RFC7517]. Any other encodings MUST NOT be allowed.

Issue 4

The specific encoding of BBS public key parameters are being discussed in the JOSE Working Group.

Developers are advised to not accidentally publish a representation of a private key. Implementations of this specification MUST raise errors in the event of the expression of a key parameter that is marked as Private in the IANA JSON Web Key Parameters registry in public key information.

Example 3: An BLS12-381 public key containing the G1 and G2 values, encoded as a JsonWebKey 
{
  "id": "did:example:123#key-3",
  "type": "JsonWebKey",
  "controller": "did:example:123",
  "publicKeyJwk": [{
    "kty": "EC",
    "crv": "BLS12381_G1",
    "x": "tCgCNuUYQotPEsrljWi-lIRIPpzhqsnJV1NPnE7je6glUb-FJm9IYkuv2hbHw22i"
  }, {
    "kty": "EC",
    "crv": "BLS12381_G2",
    "x": "h_rkcTKXXzRbOPr9UxSfegCbid2U_cVNXQUaKeGF7UhwrMJFP70uMH0VQ9-3-_2zDP
      AAjflsdeLkOXW3-ShktLxuPy8UlXSNgKNmkfb-rrj-FRwbs13pv_WsIf-eV66-"
  }]
}
Example 4: A BLS12-381 public key containing the G1 and G2 values, encoded as a JsonWebKey in a controller document 
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/data-integrity/v1"
  ],
  "id": "did:example:123",
  "verificationMethod": [{
    "id": "https://example.com/issuer/123#key-3",
    "type": "Multikey",
    "controller": "https://example.com/issuer/123",
    "publicKeyMultibase": "zDnaerx9CtbPJ1q36T5Ln5wYt3MQYeGRG5ehnPAmxcf5mDZpv"
  }, {
    "id": "did:example:123#key-3",
    "type": "JsonWebKey",
    "controller": "did:example:123",
    "publicKeyJwk": [{
      "kty": "EC",
      "crv": "BLS12381_G1",
      "x": "tCgCNuUYQotPEsrljWi-lIRIPpzhqsnJV1NPnE7je6glUb-FJm9IYkuv2hbHw22i"
    }, {
      "kty": "EC",
      "crv": "BLS12381_G2",
      "x": "h_rkcTKXXzRbOPr9UxSfegCbid2U_cVNXQUaKeGF7UhwrMJFP70uMH0VQ9-3-_2zDP
        AAjflsdeLkOXW3-ShktLxuPy8UlXSNgKNmkfb-rrj-FRwbs13pv_WsIf-eV66-"
    }]
  }],
  "authentication": [
    "did:example:123#key-3"
  ],
  "assertionMethod": [
    "did:example:123#key-4"
  ],
  "capabilityDelegation": [
    "did:example:123#key-3"
  ],
  "capabilityInvocation": [
    "did:example:123#key-3"
  ]
}

2.2 Proof Representations

This suite relies on detached digital signatures represented using [MULTIBASE] and [MULTICODEC].

2.2.1 DataIntegrityProof

The verificationMethod property of the proof MUST be a URL. Dereferencing the verificationMethod MUST result in an object containing a type property with the value set to Multikey or JsonWebKey.

The type property of the proof MUST be DataIntegrityProof.

The cryptosuite property of the proof MUST be bbs-2023.

The created property of the proof MUST be an [XMLSCHEMA11-2] formated date string.

The proofPurpose property of the proof MUST be a string, and MUST match the verification relationship expressed by the verification method controller.

The proofValue property of the proof MUST be a detached BBS Signature produced according to [CFRG-BBS-SIGNATURE], encoded according to [MULTIBASE] using the base64 base encoding with no padding.

Example 5: An BBS digital signature expressed as a DataIntegrityProof 
{
  "@context": [
    {"title": "https://schema.org/title"},
    "https://w3id.org/security/data-integrity/v1"
  ],
  "title": "Hello world!",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "bbs-2023",
    "created": "2020-11-05T19:23:24Z",
    "verificationMethod": "https://example.com/issuer/123#key-2",
    "proofPurpose": "assertionMethod",
    "proofValue": "mU6i3dTz5yFfWJ8zgsamuyZa4yAHPm75tUOOXddR6krCvCYk77sbCOuEVcdB
      Dd/l6tIYkTTbA3pmDa6Qia/JkOnIXDLmoBz3vsi7L5t3DWySI/VLmBqleJ/Tbus5RoyiDERDB
      5rnACXlnOqJ/U8yFQFtcp/mBCc2FtKNPHae9jKIv1dm9K9QK1F3GI1AwyGoUfjLWrkGDObO1o
      AhpEd0+et+qiOf2j8p3MTTtRRx4Hgjcl0jXCq7C7R5/nLpgimHAAAAdAx4ouhMk7v9dXijCIM
      0deicn6fLoq3GcNHuH5X1j22LU/hDu7vvPnk/6JLkZ1xQAAAAIPd1tu598L/K3NSy0zOy6oba
      Enaqc1R5Ih/6ZZgfEln2a6tuUp4wePExI1DGHqwj3j2lKg31a/6bSs7SMecHBQdgIYHnBmCYG
      nu/LZ9TFV56tBXY6YOWZgFzgLDrApnrFpixEACM9rwrJ5ORtxAAAAAgE4gUIIC9aHyJNa5TBk
      Oh6ojlvQkMVLXa/vEl+3NCLXblxjgpM7UEMqBkE9/aGQcoD3Tgmy+z0hN+4elMky1RnJEhCuN
      QNsEg"
  }
}

3. Algorithms

The following section describes multiple Data Integrity cryptographic suites that utilize the BBS Signature Algorithm [CFRG-BBS-SIGNATURE].

3.1 bbs-2023

The bbs-2023 cryptographic suite takes an input document, canonicalizes the document using the Universal RDF Dataset Canonicalization Algorithm [RDF-CANON], and then cryptographically hashes and signs the output resulting in the production of a data integrity proof. The algorithms in this section also include the verification of such a data integrity proof.

3.1.1 Add Proof (bbs-2023)

To generate a proof, the algorithm in Section 4.1: Add Proof in the Data Integrity [VC-DATA-INTEGRITY] specification MUST be executed. For that algorithm, the cryptographic suite specific transformation algorithm is defined in Section 3.1.3 Transformation (bbs-2023), the hashing algorithm is defined in Section 3.1.4 Hashing (bbs-2023), and the proof serialization algorithm is defined in Section 3.1.6 Proof Serialization (bbs-2023).

3.1.2 Verify Proof (bbs-2023)

To verify a proof, the algorithm in Section 4.2: Verify Proof in the Data Integrity [VC-DATA-INTEGRITY] specification MUST be executed. For that algorithm, the cryptographic suite specific transformation algorithm is defined in Section 3.1.3 Transformation (bbs-2023), the hashing algorithm is defined in Section 3.1.4 Hashing (bbs-2023), and the proof verification algorithm is defined in Section 3.1.7 Proof Verification (bbs-2023).

3.1.3 Transformation (bbs-2023)

The following algorithm specifies how to transform an unsecured input document into a transformed document that is ready to be provided as input to the hashing algorithm in Section 3.1.4 Hashing (bbs-2023).

Required inputs to this algorithm are an unsecured data document (unsecuredDocument) and transformation options (options). The transformation options MUST contain a type identifier for the cryptographic suite (type) and a cryptosuite identifier (cryptosuite). A transformed data document is produced as output. Whenever this algorithm encodes strings, it MUST use UTF-8 encoding.

  1. If options.type is not set to the string DataIntegrityProof and options.cryptosuite is not set to the string bbs-2023 then a PROOF_TRANSFORMATION_ERROR MUST be raised.
  2. Let canonicalDocument be the result of applying the Universal RDF Dataset Canonicalization Algorithm [RDF-CANON] to the unsecuredDocument.
  3. Set output to the value of canonicalDocument.
  4. Return canonicalDocument as the transformed data document.

3.1.4 Hashing (bbs-2023)

The following algorithm specifies how to cryptographically hash a transformed data document and proof configuration into cryptographic hash data that is ready to be provided as input to the algorithms in Section 3.1.6 Proof Serialization (bbs-2023) or Section 3.1.7 Proof Verification (bbs-2023).

The required inputs to this algorithm are a transformed data document (transformedDocument) and proof configuration (proofConfig). A single hash data value represented as series of bytes is produced as output.

    Issue 5
  1. Specify how each item in the canonicalized input is hashed and included a set that is then signed over in 3.1.6 Proof Serialization (bbs-2023).
    2. Issue 6
  2. Specify how proofConfigHash is generated.
    3. Issue 7
  3. Specify how hashData is composed in a way that can be signed over in 3.1.6 Proof Serialization (bbs-2023).
  4. Return hashData as the hash data.

3.1.5 Proof Configuration (bbs-2023)

The following algorithm specifies how to generate a proof configuration from a set of proof options that is used as input to the proof hashing algorithm.

The required inputs to this algorithm are proof options (options). The proof options MUST contain a type identifier for the cryptographic suite (type) and MUST contain a cryptosuite identifier (cryptosuite). A proof configuration object is produced as output.

  1. Let proofConfig be an empty object.
  2. Set proofConfig.type to options.type.
  3. If options.cryptosuite is set, set proofConfig.cryptosuite to its value.
  4. If options.type is not set to DataIntegrityProof and proofConfig.cryptosuite is not set to bbs-2023, an INVALID_PROOF_CONFIGURATION error MUST be raised.
  5. Set proofConfig.created to options.created. If the value is not a valid [XMLSCHEMA11-2] datetime, an INVALID_PROOF_DATETIME error MUST be raised.
  6. Set proofConfig.verificationMethod to options.verificationMethod.
  7. Set proofConfig.proofPurpose to options.proofPurpose.
  8. Return proofConfig.

3.1.6 Proof Serialization (bbs-2023)

The following algorithm specifies how to serialize a digital signature from a set of cryptographic hash data. This algorithm is designed to be used in conjunction with the algorithms defined in the Data Integrity [VC-DATA-INTEGRITY] specification, Section 4: Algorithms. Required inputs are cryptographic hash data (hashData) and proof options (options). The proof options MUST contain a type identifier for the cryptographic suite (type) and MAY contain a cryptosuite identifier (cryptosuite). A single digital proof value represented as series of bytes is produced as output.

  1. Let privateKeyBytes be the result of retrieving the private key bytes associated with the options.verificationMethod value as described in the Data Integrity [VC-DATA-INTEGRITY] specification, Section 4: Retrieving Cryptographic Material.
    2. Issue 8
  2. Specify how proofBytes is generated and consumed by Section 3.1.7 Proof Verification (bbs-2023).
  3. Return proofBytes as the digital proof.

3.1.7 Proof Verification (bbs-2023)

The following algorithm specifies how to verify a digital signature from a set of cryptographic hash data. This algorithm is designed to be used in conjunction with the algorithms defined in the Data Integrity [VC-DATA-INTEGRITY] specification, Section 4: Algorithms. Required inputs are cryptographic hash data (hashData), a digital signature (proofBytes) and proof options (options). A verification result represented as a boolean value is produced as output.

  1. Let publicKeyBytes be the result of retrieving the public key bytes associated with the options.verificationMethod value as described in the Data Integrity [VC-DATA-INTEGRITY] specification, Section 4: Retrieving Cryptographic Material.
  2. Let verificationResult be the result of applying the verification algorithm defined in the BBS Signature specification [CFRG-BBS-SIGNATURE], with hashData as the data to be verified against the proofBytes using the public key specified by publicKeyBytes.
  3. Return verificationResult as the verification result.

4. Security Considerations

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

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

A. BBS+ Signature 2020

A.1 BLS12-381

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.

Issue 10
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.

A.1.1 Bls 12-381 G1 Public Key

The following section defines the representation of the Bls12381G1Key2020

The keys definition MUST have an attribute of publicKeyBase58 and its value MUST be a base58 encoded BLS12-381 public key in the G1 field. Where the BLS12-381 public key is the raw 48 byte x co-ordinate defining the commitment.

A simple example of a Bls12381G1Key2020:

Example 6: base58 encoded BLS12-381 G1 Key 
{
  "id": "did:example:123#key-0",
  "type": "Bls12381G1Key2020",
  "controller": "did:example:123",
  "publicKeyBase58": "7cJGQwV5XyzUjJEzY5doVhv62Qqou6qW7G4eh9YbUywgyeDCobiXjN8CnQ7wpWBrGR",
}
Example 7: JWK encoded BLS12-381 G1 Key 
{
  "id": "did:example:123#key-0",
  "type": "Bls12381G1Key2020",
  "controller": "did:example:123",
  "publicKeyJwk": {
    "kty": "EC",
    "crv": "BLS12381_G1",
    "x": "tCgCNuUYQotPEsrljWi-lIRIPpzhqsnJV1NPnE7je6glUb-FJm9IYkuv2hbHw22i"
  }
}

A.1.2 Bls 12-381 G2 Public Key

The following section defines the representation of the Bls12381G2Key2020

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:

Example 8: base58 encoded BLS12-381 G2 Key 
{
  "id": "did:example:123#key-1",
  "type": "Bls12381G2Key2020",
  "controller": "did:example:123",
  "publicKeyBase58" : "oqpWYKaZD9M1Kbe94BVXpr8WTdFBNZyKv48cziTiQUeuhm7sBhCABMyYG4kcMrseC68YTFFgyhiNeBKjzdKk9MiRWuLv5H4FFujQsQK2KTAtzU8qTBiZqBHMmnLF4PL7Ytu"
}
Example 9: JWK encoded BLS12-381 G2 Key 
{
  "id": "did:example:123#key-1",
  "type": "Bls12381G2Key2020",
  "controller": "did:example:123",
  "publicKeyJwk": {
    "crv": "BLS12381_G2",
    "kty": "EC",
    "x": "h_rkcTKXXzRbOPr9UxSfegCbid2U_cVNXQUaKeGF7UhwrMJFP70uMH0VQ9-3-_2zDPAAjflsdeLkOXW3-ShktLxuPy8UlXSNgKNmkfb-rrj-FRwbs13pv_WsIf-eV66-"
  }
}

A.2 The BBS+ Signature Suite 2020

The BBS+ signature suite 2020 MUST be used in conjunction with the signing and verification algorithms in the Data Integrity [DATA-INTEGRITY] specification. The suite consists of the following algorithms:

Parameter Value Specification
canonicalization algorithm https://w3id.org/security#URDNA2015 [RDF-DATASET-NORMALIZATION]
statement digest algorithm Blake2b [BLAKE2]
signature algorithm BBS+ Signature [BBS]
curve name BLS12-381 [PAIRING-FRIENDLY-CURVES]

A.2.1 Modification to Algorithms

A.2.1.1 Create Verify Data Algorithm

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.

  1. Canonicalize the input document using the canonicalization algorithm to a set of statements represented as n-quads.
  2. Initialize an empty array of length equal to the number of statements, let this be known as the statement digests array.
  3. For each statement in order:
    1. Apply the statement digest algorithm to obtain a statement digest
    2. 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.
  4. Returned the statement digests array.

A.2.2 Terms

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

A.2.2.1 Proof Type

To identify the type of data integrity proof that is attached to a linked data document, the type attribute defined in [DATA-INTEGRITY].

The term of BbsBlsSignature2020 is used to indicate when a data integrity proof is of type BBS+ Signature.

A linked data document featuring a BBS+ Signature data integrity proof MUST contain a proof element thats has a type equal to BbsBlsSignature2020.

Example 10 
{
  "@context": [
    "http://schema.org/",
    "https://w3id.org/security/v2",
    "https://w3id.org/security/bbs/v1"
  ],
  "@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",
    "proofValue": "F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg==",
    "requiredRevealStatements": [ 4, 5 ]
  }
}
A.2.2.2 Created

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 [DATA-INTEGRITY].

A linked data document featuring a BBS+ Signature data integrity proof MAY contain a created attribute with value a value corresponding to an [ISO8601] combined date and time string.

Example 11 
{
  "@context": [
    "http://schema.org/",
    "https://w3id.org/security/v2",
    "https://w3id.org/security/bbs/v1"
  ],
  "@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",
    "proofValue": "F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg==",
    "requiredRevealStatements": [ 4, 5 ]
  }
}
A.2.2.3 @context

When using [JSON-LD] to exchange data between more than one software system, it's important to use terminology that both of the software systems can understand. In [JSON-LD] this common terminology is identified with the usage of URIs. However, those URIs can be long and not human friendly for implementors to work with. In such cases, aliases that are presented in a short-form can be used to ease this burden. This specification relies on the @context property in [JSON-LD] to short-form aliases to long form URIs required by this signature suite. It's RECOMMENDED that https://w3id.org/security/bbs/v1 is used within the @context property to map the short-form aliases to long form URIs.

Example 12 
{
  "@context": [
    "http://schema.org/",
    "https://w3id.org/security/v2",
    "https://w3id.org/security/bbs/v1"
  ],
  "@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",
    "proofValue": "F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg==",
    "requiredRevealStatements": [ 4, 5 ]
  }
}
A.2.2.4 Verification Method

When verifying a digital signature, public key material of the signer is required, the verificationMethod attribute is used to communicate this as defined in [DATA-INTEGRITY].

A linked data document featuring a BBS+ Signature data integrity proof MUST contain a verificationMethod attribute with a value that is either the verification method required to verify the data integrity proof or a URI that when dereferenced results in the verification method required to verify the data integrity proof.

The verification method MUST be of type Bls12381G2Key2020.

Example 13 
{
  "@context": [
    "http://schema.org/",
    "https://w3id.org/security/v2",
    "https://w3id.org/security/bbs/v1"
  ],
  "@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",
    "proofValue": "F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg==",
    "requiredRevealStatements": [ 4, 5 ]
  }
}
A.2.2.5 Proof Purpose

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 data integrity proof MUST contain a proofPurpose attribute with a value that is defined in [DATA-INTEGRITY].

Example 14 
{
  "@context": [
    "http://schema.org/",
    "https://w3id.org/security/v2",
    "https://w3id.org/security/bbs/v1"
  ],
  "@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",
    "proofValue": "F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg==",
    "requiredRevealStatements": [ 4, 5 ]
  }
}
A.2.2.6 Required Reveal Statements

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 data integrity 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 data integrity proof MUST always be present.

Example 15 
{
  "@context": [
    "http://schema.org/",
    "https://w3id.org/security/v2",
    "https://w3id.org/security/bbs/v1"
  ],
  "@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",
    "proofValue": "F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg==",
    "requiredRevealStatements": [ 4, 5 ]
  }
}
A.2.2.7 Proof Value

The raw 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 data integrity proof MUST contain a proofValue attribute with value defined by the signing algorithm described in this specification.

Issue 11
TODO: Define the encoding scheme for the signature value
Example 16 
{
  "@context": [
    "http://schema.org/",
    "https://w3id.org/security/v2",
    "https://w3id.org/security/bbs/v1"
  ],
  "@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",
    "proofValue": "F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg==",
    "requiredRevealStatements": [ 4, 5 ]
  }
}

A.3 The BBS+ Signature Proof Suite 2020

A BBS proof of knowledge data integrity proof is a proof that is derived from a BbsBlsSignature2020 data integrity 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 Data Integrity [DATA-INTEGRITY] specification. The suite consists of the following algorithms:

Parameter Value Specification
canonicalization algorithm https://w3id.org/security#URDNA2015 [RDF-DATASET-NORMALIZATION]
statement digest algorithm Blake2b [BLAKE2]
signature algorithm BBS+ Signature [BBS]
curve name BLS12-381 [PAIRING-FRIENDLY-CURVES]

A.3.1 Terms

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

A.3.1.1 Proof Type

To identify the type of data integrity proof that is attached to a linked data document, the type attribute is used as defined in [DATA-INTEGRITY].

The term of BbsSignatureProof2020 is used to indicate when a data integrity proof is of type BBS+ proof of knowledge.

A linked data document featuring a BBS+ proof of knowledge data integrity proof MUST contain a type attribute thats has a type equal to BbsSignatureProof2020.

Example 17 
{
  "@context": [
    "http://schema.org/",
    "https://w3id.org/security/v2",
    "https://w3id.org/security/bbs/v1"
  ],
  "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.3.1.2 Created
Issue 12
TODO: Add paragraph?

A linked data document featuring a BBS+ Signature data integrity proof MAY contain a created attribute with value a value corresponding to an [ISO8601] combined date and time string.

Example 18 
{
  "@context": [
    "http://schema.org/",
    "https://w3id.org/security/v2",
    "https://w3id.org/security/bbs/v1"
  ],
  "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.3.1.3 Verification Method

A linked data document featuring a BBS+ proof of knowledge data integrity proof MUST contain a verificationMethod attribute with a value that is equal to that of the BbsBlsSignature2020 for which the proof is derived from.

Issue 13
TODO: Add paragraph?
Example 19 
{
  "@context": [
    "http://schema.org/",
    "https://w3id.org/security/v2",
    "https://w3id.org/security/bbs/v1"
  ],
  "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.3.1.4 Proof Purpose
Issue 14
TODO: Add paragraph?

A linked data document featuring a BBS+ proof of knowledge data integrity proof MUST contain a proofPurpose attribute with a value that is equal to that of the BbsBlsSignature2020 for which the proof is derived from.

Example 20 
{
  "@context": [
    "http://schema.org/",
    "https://w3id.org/security/v2",
    "https://w3id.org/security/bbs/v1"
  ],
  "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.3.1.5 Proof Value

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 data integrity proof MUST contain a proofValue attribute with value defined by the derive proof algorithm described in this specification.

Example 21 
{
  "@context": [
    "http://schema.org/",
    "https://w3id.org/security/v2",
    "https://w3id.org/security/bbs/v1"
  ],
  "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.3.1.6 Nonce

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 data integrity proof MUST contain a nonce attribute.

Example 22 
{
  "@context": [
    "http://schema.org/",
    "https://w3id.org/security/v2",
    "https://w3id.org/security/bbs/v1"
  ],
  "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="
  }
}

A.4 The BBS+ Bound Signature Suite 2020

The BBS+ Bound signature suite 2020 adds a mechanism for recipient binding, and is otherwise identical, to the BBS+ signature suite 2020. It MUST be used in conjunction with the signing and verification algorithms in the Data Integrity [DATA-INTEGRITY] specification. The suite consists of the following algorithms:

Parameter Value Specification
canonicalization algorithm https://w3id.org/security#URDNA2015 [RDF-DATASET-NORMALIZATION]
statement digest algorithm Blake2b [BLAKE2]
signature algorithm BBS+ Signature [BBS]
curve name BLS12-381 [PAIRING-FRIENDLY-CURVES]

A.4.1 Modification to Algorithms

A.4.1.1 Create Verify Data Algorithm

The create verify data algorithm defined below is identical to the create verify data algorithm defined for the BBS+ signature suite 2020, with the addition of steps to include recipient binding.

The algorithm defined below outlines the process of obtaining the data in the form required for both signing and verifying, plus the data required to bind to a recipient

  1. Obtain a blind message which is a commitment to a secret value as described in [BBS] section 3.9. This is the recipient binding commitment.
  2. Initialize an empty array of length equal to the number of statements not including the recipient binding commitment; let this be known as the statement digests array.
  3. Use the canonicalization algorithm to canonicalize the input document to a set of statements represented as n-quads.
  4. For each statement in order:
    1. Apply the statement digest algorithm to obtain a statement digest
    2. 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.
  5. Return the statement digests array and the recipient binding commitment.

A.4.2 Terms

The following section outlines the terms used by the BBS+ Bound Signature Suite which differ from those terms used by the BBS+ Signature Suite. All other terms are the same in both suites.

A.4.2.1 Proof Type

Use the type attribute defined in [DATA-INTEGRITY] to identify the type of data integrity proof that is attached to a linked data document.

The term BbsBlsBoundSignature2020 is used to indicate when a data integrity proof is of type BBS+ Bound Signature.

A linked data document featuring a BBS+ Bound Signature data integrity proof MUST contain a proof element that has a type equal to BbsBlsBoundSignature2020.

Example 23 
{
  "@context": [
    "http://schema.org/",
    "https://w3id.org/security/v2",
    "https://w3id.org/security/bbs/v1"
  ],
  "@type": "Person",
  "firstName": "Jane",
  "lastName": "Does",
  "jobTitle": "Professor",
  "telephone": "(425) 123-4567",
  "email": "jane.doe@example.com",
  "proof": {
    "type": "BbsBlsBoundSignature2020",
    "created": "2020-04-25",
    "verificationMethod": "did:example:489398593#test",
    "proofPurpose": "assertionMethod",
    "proofValue": "F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg=="
  }
}

A.5 The BBS+ Bound Signature Proof Suite 2020

A BBS bound proof of knowledge data integrity proof is a proof that is derived from a BbsBlsBoundSignature2020 data integrity proof where a sub-set of the original statements are revealed.

The BBS+ bound proof of knowledge signature suite MUST be used in conjunction with the signing and verification algorithms in the Linked Data Proofs [DATA-INTEGRITY] specification. It adds a proof of recipient binding, and is otherwise identical, to the BBS+ proof of knowledge signature suite. The suite consists of the following algorithms:

Parameter Value Specification
canonicalization algorithm https://w3id.org/security#URDNA2015 [RDF-DATASET-NORMALIZATION]
statement digest algorithm Blake2b [BLAKE2]
signature algorithm BBS+ Signature [BBS]
curve name BLS12-381 [PAIRING-FRIENDLY-CURVES]

A.5.1 Terms

The following section outlines the terms used by the BBS+ bound proof of knowledge signature suite which differ from those terms used by the BBS+ proof of knowledge. All other terms are the same in both suites.

A.5.1.1 Proof Type

The type attribute is used to identify the type of data integrity proof that is attached to a linked data document as defined in [DATA-INTEGRITY].

The term BbsBoundSignatureProof2020 is used to indicate when a data integrity proof is of type BBS+ bound proof of knowledge.

A linked data document featuring a BBS+ bound proof of knowledge data integrity proof MUST contain a type attribute with a value of BbsBoundSignatureProof2020.

Example 24 
{
  "@context": [
    "http://schema.org/",
    "https://w3id.org/security/v2",
    "https://w3id.org/security/bbs/v1"
  ],
  "id": "urn:bnid:_:c14n0",
  "email": "jane.doe@example.com",
  "firstName": "Jane",
  "jobTitle": "Professor",
  "lastName": "Does",
  "telephone": "(425) 123-4567",
  "proof": {
    "type": "BbsBlsBoundSignatureProof2020",
    "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.6 Derive Proof Algorithm

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

Issue 15
TODO: Add examples and full definition of this algorithm

A.6.1 Create Derive Proof Data Algorithm

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

input proof document
A data integrity proof document featuring a data integrity proof that supports proof derivation.
reveal document
A JSON-LD document in the form of a frame which describes the desired transform to apply to the input proof document using the framing algorithm defined in [JSON-LD-FRAMING].
revealed document
A data integrity proof document which is the product of the derive proof algorithm.
  1. 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.
  2. Record the total number of statements in the input proof document statements. Let this be known as the total statements.
  3. Apply the framing algorithm to the input proof document. Let the product of the framing algorithm be known as the revealed document.
  4. 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.
  5. Initialize an empty array of length equal to the number of revealed statements. Let this be known as the revealed indicies array.
  6. For each statement in order:
    1. Find the numerical index the statement occupies in the set input proof document statements.
    2. Insert this numerical index into the revealed indicies array
  7. Returned the revealed indicies array, total statements and input proof document statements.
Issue 16
TODO: Define how we have to validate the requiredRevealStatements
Issue 17
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

B. Acknowledgements

Portions of the work on this specification have been funded by the United States Department of Homeland Security's (US DHS) Silicon Valley Innovation Program under contracts 70RSAT20T00000003, and 70RSAT20T00000033. The content of this specification does not necessarily reflect the position or the policy of the U.S. Government and no official endorsement should be inferred.

C. References

C.1 Normative references

[BBS]
BBS+ Signatures. Michael Lodder; Tobias Looker. Draft. URL: https://mattrglobal.github.io/bbs-signatures-spec/
[BLAKE2]
Blake2 - fast secure hashing. URL: https://www.blake2.net/
[CFRG-BBS-SIGNATURE]
The BBS Signature Scheme. Tobias Looker; Vasilis Kalos; Andrew Whitehead; Mike Lodder. Draft. URL: https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-02.html
[DATA-INTEGRITY]
Data Integrity 1.0. David Longley; Manu Sporny. Credentials Community Group. CGDRAFT. URL: https://w3c-ccg.github.io/data-integrity-spec/
[DID-CORE]
Decentralized Identifiers (DIDs) v1.0. Manu Sporny; Amy Guy; Markus Sabadello; Drummond Reed. W3C. 19 July 2022. W3C Recommendation. URL: https://www.w3.org/TR/did-core/
[ISO8601]
Representation of dates and times. ISO 8601:2004.. International Organization for Standardization (ISO). 2004. ISO 8601:2004. URL: http://www.iso.org/iso/catalogue_detail?csnumber=40874
[JSON-LD]
JSON-LD 1.1. Dave Longley; Gregg Kellogg; Pierre-Antoine Champin. W3C. Candidate Recommendation. URL: https://www.w3.org/TR/json-ld11
[JSON-LD-FRAMING]
JSON-LD 1.1 Framing. Dave Longley; Gregg Kellogg; Pierre-Antoine Champin. W3C. Candidate Recommendation. URL: https://www.w3.org/TR/json-ld11-framing
[MULTIBASE]
Multibase. URL: https://tools.ietf.org/html/draft-multiformats-multibase-01
[MULTICODEC]
Multicodec. URL: https://github.com/multiformats/multicodec/
[PAIRING-FRIENDLY-CURVES]
Pairing-Friendly Curves. Yumi Sakemi; Tetsutaro Kobayashi; Tsunekazu Saito. IETF. Internet Draft. URL: https://tools.ietf.org/html/draft-irtf-cfrg-pairing-friendly-curves-03
[RDF-CANON]
RDF Dataset Canonicalization. Dave Longley; Gregg Kellogg; Dan Yamamoto. W3C. 10 April 2023. W3C Working Draft. URL: https://www.w3.org/TR/rdf-canon/
[RDF-CONCEPTS]
RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
[RDF-DATASET-NORMALIZATION]
RDF Dataset Normalization 1.0. David Longley; Manu Sporny. JSON-LD Community Group. CGDRAFT. URL: http://json-ld.github.io/normalization/spec/
[RDF-N-Quads]
RDF 1.1 N-Quads. Gaven Carothers. Recommendation. URL: http://json-ld.github.io/normalization/spec/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3986
[RFC7517]
JSON Web Key (JWK). M. Jones. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7517
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[VC-DATA-INTEGRITY]
Verifiable Credential Data Integrity 1.0. Manu Sporny; Dave Longley; Michael Prorock. W3C. 8 April 2023. W3C Working Draft. URL: https://www.w3.org/TR/vc-data-integrity/
[XMLSCHEMA11-2]
W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/

C.2 Informative references

[VC-DATA-MODEL-2]
Verifiable Credentials Data Model v2.0. Manu Sporny; Dave Longley; Grant Noble; Dan Burnett; Ted Thibodeau; Brent Zundel; David Chadwick; Kyle Den Hartog. W3C Verifiable Credentials Working Group. Working Draft. URL: https://www.w3.org/TR/vc-data-model-2.0/