The Proof struct includes a 32-byte field named oracle, with the comment "nonce used to define the random oracle". I think this means it is passed to transcript.init()as thesession_id` argument. I think this field should be removed for a few different reasons.
Firstly, most protocols using this proof system will already have a way to communicate whatever transport protocol binding value or liveness nonce that they need hashed into the Fiat-Shamir transcript. Having the prover send these bytes in its serialized proof is redundant and opens up the possibility of using the prover's copy of the session ID without comparing it to the verifier's copy. For instance, if in some protocol, the verifier chooses this nonce to enforce liveness, and sends it to the prover, then the prover sending it back to the verifier again would be redundant.
I took a look at the reference verifier service, written in Go, and it uses ISO 18013-5 with OpenID4VP handoff. In this server, the Fiat-Shamir transcript is initialized with the serialized SessionTranscript structure. Both the mdoc and the mdoc reader need to already know and agree upon this value for various protocol security features.
This brings me to my second reason for dropping this field. In the above use case, the session_id is not 32 bytes, but is variable length.
Third, while section 7.5 discusses the multi-field optimization, including this oracle field in the Proof struct doesn't make sense in that context. In the multi-field protocol, all sub-protocols share one common Fiat-Shamir transcript. This means that, even if the prover transmits the session_id argument as part of its proof, it should be stored one level up, since it is not a per-circuit parameter.
The
Proofstruct includes a 32-byte field namedoracle, with the comment "nonce used to define the random oracle". I think this means it is passed to transcript.init()as thesession_id` argument. I think this field should be removed for a few different reasons.Firstly, most protocols using this proof system will already have a way to communicate whatever transport protocol binding value or liveness nonce that they need hashed into the Fiat-Shamir transcript. Having the prover send these bytes in its serialized proof is redundant and opens up the possibility of using the prover's copy of the session ID without comparing it to the verifier's copy. For instance, if in some protocol, the verifier chooses this nonce to enforce liveness, and sends it to the prover, then the prover sending it back to the verifier again would be redundant.
I took a look at the reference verifier service, written in Go, and it uses ISO 18013-5 with OpenID4VP handoff. In this server, the Fiat-Shamir transcript is initialized with the serialized
SessionTranscriptstructure. Both the mdoc and the mdoc reader need to already know and agree upon this value for various protocol security features.This brings me to my second reason for dropping this field. In the above use case, the
session_idis not 32 bytes, but is variable length.Third, while section 7.5 discusses the multi-field optimization, including this
oraclefield in theProofstruct doesn't make sense in that context. In the multi-field protocol, all sub-protocols share one common Fiat-Shamir transcript. This means that, even if the prover transmits thesession_idargument as part of its proof, it should be stored one level up, since it is not a per-circuit parameter.