Bound BBS signatures

[BasileiosKal]

Hey all!

Posting a first draft of bound BBS signatures, using BLS key pairs: https://basileioskal.github.io/bbs-bound-signatures/draft-bound-bbs-signatures.html

You can find the repo here

(for context see also #28 and #37)

[OR13]

Can you make the html link show up in the github page fro the repo?

[tplooker]

Discussed on WG call 1st of May, In order to better support this draft we have identified a couple of places that the core draft could be better, @BasileiosKal will raise some issues to capture these concepts.

[Wind4Greg]

Hi Vasilis, I did an initial read. I think the curve BLS12-381 curve library I use has a pretty good BLS signature implementation. Let us know if/when you've got some test vectors and I can try a JavaScript implementation. Cheers Greg

[BasileiosKal]

@OR13 made the link available. You can find it here or from the README. Thank you for the recommendation!

[BasileiosKal]

@Wind4Greg That's awesome!! We have an implementation of the draft so we will be able to post some test vectors soon. Thank you!

[andrewwhitehead]

It seems like the verification is missing a way to pass in the BP_1 generator point to BbsVerify. We might need to add a CoreProofVerify operation which is called by ProofVerify and accepts the list of generators as input.

I'm a little unsure about just adding BBS_BOUND to the header instead of defining a new ciphersuite, since signing is not the same operation.

For our applications I think I would also prefer a zero-knowledge proof of key possession and blind signing similar to the old implementation, but that would lose the benefit of delegating to the BLS draft.

[BasileiosKal]

Thanks for the feedback @andrewwhitehead 🙏

It seems like the verification is missing a way to pass in the BP_1 generator point to BbsVerify.

BbsVerify should be using this create_generators. Wouldn't this be enough??

I'm a little unsure about just adding BBS_BOUND to the header instead of defining a new ciphersuite,

I agree. This was a temporally solution until we define a new ciphersuite. The structure of a bound ciphersuite will depend on the flexibility of the core draft, so waiting for that discussion there to move on a bit first.

For our applications I think I would also prefer a zero-knowledge proof of key possession and blind signing similar to the old implementation, but that would lose the benefit of delegating to the BLS draft.

As an alternative, we could also make one document that encapsulates both generic Schnorr-like commitments and BLS signatures. The flow is the same, so we could define commitmentGen in a commitmentVerify in a generic way.

[andrewwhitehead]

BbsVerify should be using this create_generators. Wouldn't this be enough??

I missed that create_generators is redefined, I think that does simplify things.

[matsutakk]

Hi, I'm interested in this, any updates??

[matthiasgeihs]

hey, does there exist a prototype implementation of this?

[matthiasgeihs]

@Wind4Greg have you found the time to code up a prototype?

[Wind4Greg]

Hi @matthiasgeihs we are using Blind BBS Signatures to implement a form of holder binding for verifiable credentials VC-DI=BBS: anonymous holder binding. My implementation of Blind BBS can be found at https://github.com/Wind4Greg/grotto-bbs-signatures. Cheers Greg

[matthiasgeihs]

Hi @Wind4Greg, thank you for your reply.

Can the holder secret be used to create signatures on other documents as well?

Use case: A credential holder wants to sign a different document using the holder secret. The holder also wants to prove that the signature was created by someone who fulfills certain properties certified in the holder credential. The holder doesn't want to reveal anything else about its identity (i.e., signature and proofs should be zero-knowledge).