Consider including bbsHeader in base proof to simplify disclosure / derived proof implementations

[dlongley]

If we include the bbsHeader in the base proof at a cost of 64 bytes (as it comprises proofHash of 32 bytes and mandatoryHash of 32 bytes) then disclosure implementations do not need to reproduce these values themselves and can just include them in the BBS ProofGen call.

Including this in the base proof (which is not retransmitted for presentation to verifiers) seems like it's probably worth the trade off of reduced complexity for derived proof implementers.

[Wind4Greg]

Hmm, when a holder receives the base proof they need to verify it and hence recompute/calculate proofHash and mandatoryHash as part of verification. Couldn't they save it then? Sending it seems a bit redundant since they are supposed to calculate as part of verification. Could we make informational notes that they can cache or otherwise save the values for use in creating derived proofs.

[dlongley]

I don't think we should assume every holder (their software) will verify the BBS signature upon receipt after receiving the VC from a trusted issuer over a trusted channel. It lowers the implementation burden and ability for wallets to get support if we don't have a hard requirement on that. There might be implementers that need to move quickly to support BBS presentation -- and may only opt to add additional local verification later.

On top of this, if we were to advise implementers that they could cache, etc. -- it would still be simpler if the values were made available in the base proof eliminating the need for figuring out how / where to store the cached values (and these could be confirmed during verification if holder software wanted to do so).

Finally, verification can also be performed by generating a proof and then running verification thereafter. Of course, this still means that the functions to do the checks are in the verification piece, but it keeps the disclosure implementation simpler whilst still enabling verification as desired.

In short, I think the benefits outweigh the costs and we should include those two hashes (32 bytes each) in the base proof for easier, simpler / quicker implementations to be constructed.

[dlongley]

So, in conjunction with #125, I'd say the base proof would have these things:

bbsSignature, bbsHeader, publicKey, hmacKey, and mandatoryPointers

[dlongley]

This was my issue and it was addressed by #131, closing.