Enable Pass Through of BBS Presentation header

[Wind4Greg]

This PR addresses issue #122 to enable the passing through of the BBS presentation header. This would be used between a holder and a verifier.

See the BBS draft specification section 6.4. Presentation Header Selection where use is RECOMMENDED in most use-cases. Useful for such things as preventing replay attacks, etc...

---

Preview | Diff

[dwaite]

Where does presentationHeader come from? I would have thought it would be e.g. the RDF canonicalized version of the BBS Cryptosuite proof graph, sans proofValue.

[dlongley]

Thanks! See a couple of minor suggestions.

[dlongley]

I wonder if we need a note that says that implementations can surface the presentationHeader for external use if desired (perhaps to compare a challenge or something like that in a protocol that uses the VCDM). Nothing in the spec text prevents them from doing so, but it might be helpful to have a note like this:

Note: Implementations are free to expose any component parsed from the proof data for external use or to compare them internally against externally provided values based on protocol needs. For example, an implementation might expose presentationHeader for comparison against an expected pseudo-random challenge value used in a presentation protocol.

[Wind4Greg]

@dlongley I'm thinking we put this as an informational note at the end of section 3.3.7 Verify Derived Proof (bbs-2023). Other ideas?

[dlongley]

@Wind4Greg, that sounds good.

[Wind4Greg]

Normative, multiple reviews, changes requested and made, no objections, merging.

[dlongley]

@dwaite,

Where does presentationHeader come from? I would have thought it would be e.g. the RDF canonicalized version of the BBS Cryptosuite proof graph, sans proofValue.

A hash of the canonicalized proof graph (sans proofValue) is in the BBS header -- which is not the same as the presentation header. The presentation header is a value that the presenter (aka holder / prover) can provide for a particular derived proof. This is can be used in presentation protocols to hold nonces or challenges -- or any other sort of external information that might be useful for a protocol to require be included in the proof.

[dwaite]

@dwaite,

Where does presentationHeader come from? I would have thought it would be e.g. the RDF canonicalized version of the BBS Cryptosuite proof graph, sans proofValue.

A hash of the canonicalized proof graph (sans proofValue) is in the BBS header -- which is not the same as the presentation header. The presentation header is a value that the presenter (aka holder / prover) can provide for a particular derived proof. This is can be used in presentation protocols to hold nonces or challenges -- or any other sort of external information that might be useful for a protocol to require be included in the proof.

Ahh apologies, I may have misunderstood. Is it then correct that there is no BBS Cryptosuite-based verifiable presentation holding the derived credential? Instead then, the expectation is that there is some interoperable protocol which is exchanging derived credentials, and that protocol will define the contents of presentationHeader

[dlongley]

@dwaite,

Ahh apologies, I may have misunderstood. Is it then correct that there is no BBS Cryptosuite-based verifiable presentation holding the derived credential? Instead then, the expectation is that there is some interoperable protocol which is exchanging derived credentials, and that protocol will define the contents of presentationHeader

It's still possible for someone to use a VP that contains a VC with a BBS-derived proof. The goal here is just to enable use of the presentationHeader in derived proofs so the feature is available for higher level / protocol level specs to make use of (i.e., a goal is to ensure this spec is not overly prescriptive / limiting).

[TallTed]

Probably better to resolve merge conflicts before I re-review

[Wind4Greg]

Normative, multiple reviews, changes requested and made, no objections, merging.