Need separate cryptosuite for `signature` and `proof`

[OR13]

From examples I generated...

{
  "fullDisclosure": {
    "@context": [
      {
        "@vocab": "https://www.w3.org/ns/did/controller-dependent#"
      }
    ],
    "💀": "🔥",
    "🌱": "🐋",
    "🌈": "🚀",
    "proof": {
      "type": "DataIntegrityProof",
      "cryptosuite": "bbs-signature-2023", // previously BbsBlsSignatureProof2020
      "proofValue": "uoQLBFeiZfpNcHqWcTckM05G7hyOgSgedUoeDnrqGcYQKHnuuok9gRx-1AeVKaTNYMLY9gaTNTnyyZjfDfjcBLL6VV2iXa5PbfR_xk63ca8wPUTt-DSMJ8CknEb9bxbFVG_ccpP4Gnp-3pkmLZgCNjg"
    }
  },
  "selectiveDisclosure": {
    "@context": {
      "@vocab": "https://www.w3.org/ns/did/controller-dependent#"
    },
    "@id": "urn:bnid:_:c14n0",
    "🌱": "🐋",
    "proof": {
      "type": "DataIntegrityProof",
      "cryptosuite": "bbs-proof-2023", // previously BbsBlsSignature2020
      "disclosed": [
        2
      ],
      "generators": 3,
      "proofValue": "uidRtl9Fd7p-qhKnV3nneDmcrWhdSrPz7U3Bs8QcrjE6iDjsJkFfnLd1lapvPdZDwmCqfauReBdubo95iXGyYgIzMOtbGsGkWM1yvRjkmnEkPk-xYRCGlI41wwA5e9buWsoxRXW1iXDE_nPgeRuJAEA1L773urJ37xikEdbG9UPn2-Mp-oTwIxvh9vdwtcQlkTlhLP5rxATTEkuXLjLtZiRdzXp2-kIDXBsdqvBIME7Q06RQ8KbPiFw_1P_qiwU814VkqHk-6ZYEbuTfGr5OeBAQ0GF6AQqvlA5f_U1kV6U2Di4UgHyhlh70y-VxAvzQ7H6sl5opEFhYuoHE-wncSbskU2Omv7PCDudI8B7RJq9w7UnTJuwPW5lV8jtgejsFApbQVqC7AUyrRAhPlqmYLBBtH8N1_3v0L_kf3zv3svrVrmaft2LUrwKuxrZaWzPC8aOBd9XtS4_fli6k-J1QDRmWDowiuypC0GE3l9ToB9YE"
    }
  }
}

[OR13]

@msporny @tplooker

related:

https://github.com/Wind4Greg/BBS-LinkedData/blob/master/exampleIO/signedDocBBS.json

[msporny]

Yes, we'll need to settle on a name for the signature and the proof. The suggested names above feel fine to me.

One thing we will probably want to do is fold things like disclosed and generators into the proofValue and make proofValue a CBOR structure of some kind.

Other things to consider:

• Mandatory disclosure fields
• bound signatures

I don't know what data structures are being proposed to achieve those features?

[dlongley]

Big +1 for moving all cryptographic material (proof data specifically here) representations into a binary format that is packed and stored in proofValue as a multibase-encoded value. The details should not be exposed at the JSON layer as this ends up increasing attack surface, requiring more validation surface, potentially duplicative validation, and a variety of other problems. It's also beneficial to keep the JSON-layer as simple as possible and let the cryptosuite-specific implementations just deal with their own formats which sometimes have a tendency to be crypto-specific anyway!

[OR13]

Lets discuss CBOR compression on proof in a dedicated issue:

https://github.com/w3c/vc-di-bbs/issues/80

Bound signatures should be discussed separately, here is an issue for that: https://github.com/w3c/vc-di-bbs/issues/79

...

• Mandatory disclosure fields

^ This will need to be addressed in the proof suites, above. AFAIK, it only applies to to the full disclosure case, since the selected one, already has support for this.

[OR13]

I suggest we address mandatory to disclose messages as we are currently handling disclosed in the derived proof format, as a JSON member of the the proof the original issuer signs over.

Will this work?

[OR13]

Actually I spoke too soon, we should be discussing mandatory to reveal here: https://github.com/w3c/vc-di-bbs/issues/3

and not on this issue probably...

We can close this issue, after we establish that there are 2 ciphersuites needed in the current spec.

[Wind4Greg]

Signatures and Proof values are now packed up via CBOR with "header" values used to differentiate the two. See serialize base proof and [serialize derived proof](https://w3c.github.io/vc-di-bbs/#serializederivedproofvalue.