Add at-risk marker and enable passing in pid and verifier ID for pseudonym support from BBS spec

[dlongley]

No description provided.

[Wind4Greg]

Hi folks (@dlongley, @msporny, @brentzundel, @BasileiosKal, @RockstaYT, @dwaite, @filip26, @TallTed ), there is some additional functionality that BBS based cryptosystems could provide that is being considered for standardization in two currently individual draft documents aimed at the CFRG/IETF:

• BBS per Verifier Linkability
• Blind BBS Signatures

I'm going to try, in what follows, to put together some scenarios for verifiable credentials that would use these to provide additional functionality and show what "hooks" would be needed to support them in the specification. Would like feedback on the desirability of any of these feature sets.

Some additional helpfull references are:

• The BBS Signature Scheme
• Blind signature Good introduction and reference.
• How Does a Verifier Know the Credential is Yours? by @brentzundel on link secrets and commitments.

Application Scenarios and Flows

These are primarily explained using verifiable credential terminology of issuer, holder, verifier which correspond to BBS terminology of signer, prover, verifier respectively. The main question is what is the level of interest in each of these scenarios? In addition, please correct me if I got any of these wrong! I would say in general that the additional computation burden over that for regular BBS signatures is minor, i.e., the extended algorithms are very similar to what is already done in BBS.

Anonymous Holder Binding

This "locks" a BBS signature to a secret value known only to the holder. This prevents an adversary that may have obtained the VC with base proof (BBS signature) from creating a VC with derived proof (BBS proof) that can verify without knowing the secret value. The holder needs to send a Blind BBS commitment with proof to the issuer. After verifying the commitment from the holder the issuer uses the Blind BBS extension to BBS to produce a signature over an unsigned document which is sent to the holder (no other information is needed if the signer_blind can be omitted). The holder with its information about the commitment, and the signature can use the BlindProofGen algorithm to generate the revealed document with derived proof. The verifier uses the regular BBS proof verification procedure without modification to verify the derived document.

• Additional Features: No secret information is shared between holder and issuer (only the commitment). The holder's secret value can be reused across different issues without tracking with the use of a different secret_prover_blind per issuer.
• Changes to existing information flows: Additional information is sent from holder to issuer (commitment with proof)
• Changes to algorithms: A Blind signature/verification and Blind proof generation are used. (Regular BBS proof verification.)

Pseudonym with pid known to issuer

This allows a verifier to know that a holder it has seen before is returning via a unique pseudonym value, different verifiers cannot link a holder to its pseudonym. In this pseudonym scenario the issuer generates a secret value known as a pid (prover id) and uses it as the last BBS message when computing a BBS signature over a document. In addition to the BBS signature, the pid value must be conveyed to the holder. The holder calculates a pseudonym value based on the pid and a verifier_id. This pseudonym is used in a variant of the BBS proof generation procedure to generate a proof, i.e., a revealed document with derived proof. The pseudonym must be sent to the verifier and used when verifying the proof.

• Changes to existing information flows: issuer sends created pid value along with base signature to holder. holder sends pseudonym value to verifier.
• Changes to algorithms: slightly modified signing and verification. Extended proof generation and verification procedures.
• Notes: pid value must be kept secret.
• Cryptographic Question: Are there constraints on the verifier_id? Can a well know value such as a URL be used?

Pseudonym with hidden pid

This allows a verifier to know that a holder it has seen before is returning via a unique pseudonym, different verifiers cannot link a holder to its pseudonym, nor can the issuer track the holder across verifiers. In this pseudonym scenario the holder generates a secret value known as a pid (prover id) and generates a commitment with proof on that value which is sent to the issuer. The issuer uses a procedure similar to that for Blind signing to produce a signature (document with base proof). The holder then calculates a pseudonym value based on the pid and a verifier_id. This pseudonym is used in a variant of the BBS proof generation procedure to generate a proof, i.e., a revealed document with derived proof. The pseudonym must be sent to the verifier and used when verifying the proof.

• Changes to existing information flows: holder sends commitment with proof to issuer. holder sends pseudonym value to verifier.
• Changes to algorithms: modified signing, verification, proof generation and proof verification procedures.
• Cryptographic Question: Are there constraints on the verifier_id? Can a well know value such as a URL be used?

[dlongley]

I'd say we definitely want the last one which implies support for the middle one and maybe even the first. It sounds like we need a PR to the spec that will:

1. accept an additional option when signing signaling the including of a pid (or a commitment to one, might need two different options for this),
2. an additional optional component in the base proof that includes the pid (if not blind, otherwise just a boolean signal that it's required or the commitment that was sent if necessary?),
3. an optional pseudonym component in the derived proof, and
4. spec text that says the different sign, proof, and verify calls should be made based on what's present in the base / derived proofs.

I don't think we need a normative statement on what the verifier_id must be, but we can say that a URL that unambiguously identifies a particular verifier could be used. We also don't need to say how the issuer receives any information from the holder (that can be determined by an external protocol). We just need to allow for base signing to incorporate a pid/commitment and call the right function, include a result/signal in the base proof, allowing the holder to know which proof gen function to call and what to use/insert as a param and what to include in the derived proof, such that the verifier knows which function to call and what to include as well.

[Wind4Greg]

Here's a rough outline of what I'm planning on putting into a PR

VC BBS Flows/API enhancements

• Getting info to the issuer: (a) commitment with proof (anonymous holder binding and pseudonym with hidden pid cases), (b) indication that pseudonym use is desired (either generate one or use supplied commitment with proof as basis).
• Getting info to the holder: (a) pid value if assigned by issuer (optional field bundled with signature), Can make this an optional trailing parameter fed into 3.2.1 serializeBaseProofValue (b) verifier_id ==> seems the verifier needs to communicate this via a separate mechanisms.
• Getting info to the verifier: Nothing new in the anonymous holder binding case; In either pseudonym case the pseudonym needs to be sent and this could be an optional final parameter in the proof bundle.

Procedure Updates

• Base Proof Serialization
  • Are pseudonyms require? Yes.
    • Is a commitment with proof provided? Yes. Use Enhanced BlindBBS/Pseudonym signature
    • No commitment provided. Generate pid. Use Pseudonym Signature procedure. Encode pid as additional trailing parameter to 3.2.1 serializeBaseProofValue
  • Commitment with Proof supplied but no pseudonym requirement (anonymous holder binding)
    • Use BlindBBS signature procedure. Would this be different from Pseudonym with commitment procedure?
  • No pseudonyms and no commitment supplied: Regular BBS signature procedure
• 3.3.6 Add Derived Proof (bbs-2023) would know if a commitment was used when the base signature was created and whether is it for use with a pseudonym; or if pseudonym is was requested and a pid was received. In step (3) this information would be passed to 3.2.3 createDisclosureData where in step (10) BBS Proof Generation is done.
  • If not pseudonym but commitment then BlindBBS based proof generation. No extra information goes to verifier
  • Otherwise compute pseudonym (per Pseudonym draft which needs to be enhanced for commitment case). Update 3.2.6 serializeDerivedProofValue to support optional encoding of the pseudonym value.
• 3.3.7 Verify Derived Proof (bbs-2023) During verification if a pseudonym is included with the proof bundle then we need to use the enhanced BBS Pseudonym proof verification otherwise both regular and holder binding use the same BBS proof verification procedure.

[dlongley]

Yes, the above looks great, let's get that PR in and we can iterate there on the minor details, but all of the high-levels look right to me.

[msporny]

PR #145 has been raised to address this issue. This issue will be closed once PR #145 has been merged.

[msporny]

PR #145 has been merged, closing.