Supporting use cases for blind signing

[tplooker]

Currently the spec documents a procedure for constructing BBS signatures where by some / all of the messages signed by the signer are unknown to them. This issue is to discuss the usecases for this feature and whether it should remain in scope for the core spec of whether it could be added in the form of a seperate extension specification. The tradeoff being that electing to keep blind signing in scope significantly increases deliverables for the spec in the form of multiple cryptographic operations and data structures.

Note - related to this is a discussion on how we should handle "bound" bbs signatures captured in issue #28

[christianpaquin]

When BBS+ is used to create an anonymous credentials (messages are user attributes), then there are some interesting use cases. For example, the duty of the issuer (BBS+ signer) could be performed by two entities in a federation: an attribute provider (knows the user attribute) and an issuer (secure machine holding the crypto keys), and perhaps you don't want to leak the attribute values to the issuer, but it trusts the attribute provider to set the values. Another example is to carry-over attributes from one credential to another: say the credential contains a user-ID, never disclosed but used for non-revocation proofs. A new credential could be issued or linked to another one by copying the attribute value over; a revocation would then invalidate both credentials.

Simplifying the spec is an important goal; the various signing algs are confusing to a new reader. It would be great to achieve this functionality through an extension. FWIW, that's what with did for U-Prove using the collaborative issuance extension. See also this white paper for more background on the feature, including more details of the scenarios described above.

[tplooker]

Thanks @christianpaquin this is awesome context both the usecase and the example of the model you took to accomodate it in U-Prove.

If we simply removed sections 3.7-3.11 I believe they could form part or most of the extension to do this. Provided we have an alternative proposal for holder binding such as proposed by #37

[BasileiosKal]

Another example is to carry-over attributes from one credential to another: say the credential contains a user-ID, never disclosed but used for non-revocation proofs. A new credential could be issued or linked to another one by copying the attribute value over; a revocation would then invalidate both credentials.

Very interesting use cases. Is the idea here for the holder to send a commitment with the user-ID to a new issuer? If so, how the second issuer can be sure that the holder committed to the correct user-ID (also contained in the first credential)?

an attribute provider (knows the user attribute) and an issuer (secure machine holding the crypto keys), and perhaps you don't want to leak the attribute values to the issuer, but it trusts the attribute provider to set the values.

Also would in this case be necessary for the whole procedure of blind signatures to be followed (which also involves creating Schnorr proofs about the knowledge of the attributes and the correctness of the commitment)? If the requirement is only for information to not be leaked, wouldn't just the Pedersen commitment suffice? If that is the case, maybe we should define the blind messages nizk creation and verification as optional, to support that use-case.

[christianpaquin]

Is the idea here for the holder to send a commitment with the user-ID to a new issuer? If so, how the second issuer can be sure that the holder committed to the correct user-ID (also contained in the first credential)?

Yes. Conceptually, the holder creates a presentation proof with a commitment, showing that the undisclosed attribute is the same as in its credential; after validation by the issuer, the commitment can be integrated in the new credential. The U-Prove extension above shows how to do that for Brands' credentials; the details would be slightly different for a BBS+ based credential. An analysis is required to answer the questions you raised. Bottom line, it's not a trivial thing and perhaps this justifies specifying this functionality outside of the core spec (making sure however it has the right hooks for extensions).