Tobias Looker

Discussed on WG call 15th of August, subsequent text has clarified this significantly however supporting text at the start of the relevant operations would help to resolve any outstanding ambiguity.

Discussed on WG call 8th of august, there is currently ambiguity around the endianness of scalar_to_octets that needs to be resolved.

Related to updates in #221

DIscussed on WG call 15th August, I will look through the spec to see if we have resolved the ambiguity that was previously present

In general I understand the direction of treating the protected header in this manner, however I still dont see how implementers will be able to distinguish between the two possible...

To be clear in the context of a scheme like BBS, the presentation message is somewhat akin to a protected header in the sense that it cannot be tampered with,...

> @tplooker in order to protect this header for BBS, if the verifier provides a nonce (such as part of the presentation protocol), if we create a header like {"nonce":"abcd...."}...

Also as feedback on the approach I think in general having a new header is worth exploring more.

Initial test vectors for the signature have been contributed in #67, the remaining will be contributed once the proof serialization is settled.

Adding a couple of comments here raised from #221 - Form of messages in the test vectors is unclear, you must map these to scalar first as they are raw...