Holder Binding

[BasileiosKal]

Currently the spec is missing a way to bind a signature to a user. The proposal from here is to use BLS keys. Essentially the process will be the following,

1. User creates BLS keys i.e., BLS_SK and BLS_PK in G1 (BLS_PK = P * BLS_SK ) where P a point in G1
2. The Issuer will use the BLS_PK of the user as a commitment i.e.,

A = (P1 + BLS_PK + h0 * s + h[1] * msg[1] + h[2] * msg[2] + … + h[L] * msg[L]) * (1/(e + x))

3. The user will have to know BLS_SK to derive a BBS+ proof creating the binding.

An issue is what base points to use i.e., P (base point for use with BLS) and P1 (base point for use with BBS+). Those points need to be different. A choice is to use P as defined by the BLS signatures spec, which is the base point of G1 as defined from the pairing-friendly-curves-draft spec.

The advantage is that BLS will most likely use the base point as defined by the pairing-friendly-curves spec, so we will be in spec when it comes to BLS keys. The negative is that we will need to define a different base point for BBS+ (i.e, P1). My proposal is to just use P1 = P*2. Another option is to use a random point in G1 as the base point for BBS+ if there is some security reason to do so.

[tplooker]

To be clear this proposal would yield a couple of use-ability benefits

1. The commitment required by the issuer of the BBS signature to construct a bound variant is just an ordinary public key in G1, so no need to standardise the representation of new cryptographic information
2. The pop mechanism used by a holder to proove to an issuer they possess the private key associated to the supplied public key for binding becomes just an ordinary BLS signature, so no need to standardise the representation of new cryptographic information here and a protocol to support it (e.g creating some form of POP and verifying it)

[tplooker]

Together with this in place if agreed I think would allow us to remove the more general blind sign API from the core draft if we fail to find substantive use cases justifying its presence, discussed more in #29

[BasileiosKal]

To be clear this proposal would yield a couple of use-ability benefits

1. The commitment required by the issuer of the BBS signature to construct a bound variant is just an ordinary public key in G1, so no need to standardise the representation of new cryptographic information
2. The pop mechanism used by a holder to proove to an issuer they possess the private key associated to the supplied public key for binding becomes just an ordinary BLS signature, so no need to standardise the representation of new cryptographic information here and a protocol to support it (e.g creating some form of POP and verifying it)

Exactly. The main goal is to make the spec simpler and more readable. In compliance with the discussion at #29 the idea is that if people just want to use the core operations of bbs+ (for example for use-cases like #39) they can do so without having to concern themselves with the details of blind signatures (which do take a significant amount of the spec currently). On the other hand, for use-cases like the ones proposed here, people can just as easily use the spec extension.

[tplooker]

After thinking about this more I propose that any formal support for a BBS signature that features a cryptographic binding to the holder / prover be left to an extension spec, this keeps the core BBS signature scheme draft simple and focused

[BasileiosKal]

Discussed on WG call on 20th of Mar. Will revisit after re-viewing the latest academic works.

[tplooker]

Closing in favour of #262 where the new discussion is being had.