Pseudonyms and Anonymous Holder Binding optional features #145
Conversation
Wind4Greg
requested review from
msporny,
dlongley,
iherman,
dmitrizagidulin,
TallTed,
brianorwhatever,
decentralgabe and
brentzundel
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
index.html
Outdated
| If |commitment_with_proof| is empty and |use_pseudonyms| is true. Generate a | ||
| cryptographically random 32 byte |pid| value. Compute the |
There was a problem hiding this comment.
I think we should organize this such that you either pass in pid or not -- not that we require implementations to generate a random value for it. We can make a suggestion that that's one way to do it, but it should be done externally, IMO, and passed in. So it may be that we either have commitment_with_proof or pid passed here (it's an error to pass both) -- and then just one of them is used internally. This prevents us from being rigidly opinionated on how pid is generated.
|
It seems that this is less about "Pseudonyms" in general, and more about "Pseudonymous Holders"... If that's correct, some further exploration/clarification in the text seems warranted. |
|
Yes, @TallTed the pseudonyms are for the holder but they are tied to a verifier. I'm doing some technical updates so will try to add a bit more explanation. |
…igner_blind parameter.
…le parameters used.
…to support optional features.
…unctuation, and formatting improvements. Co-authored-by: Ted Thibodeau Jr <[email protected]>
index.html
Outdated
| the `bbsSignature` using the `Sign` procedure of [[CFRG-Blind-BBS-Signature]] | ||
| and [[CFRG-Pseudonym-BBS-Signature]], with appropriate key material, `bbsHeader` | ||
| for the `header`, `bbsMessages` for the `messages`, and |commitment_with_proof| | ||
| for the `commitment_with_proof`. If the signing procedure uses the optional | ||
| |signer_blind| parameter retain this value for use when calling | ||
| <a href="#serializebaseproofvalue"></a> below. | ||
| This provides for the "pseudonym with hidden pid" feature. |
There was a problem hiding this comment.
This must be answered before the suggestion can be complete: Is it using the `Sign` procedure of both [[CFRG-Blind-BBS-Signature]] and [[CFRG-Pseudonym-BBS-Signature]]? Or is it using the `Sign` procedure of whichever is relevant, Blind or Pseudonym [[CFRG-Blind-BBS-Signature]] or [[CFRG-Pseudonym-BBS-Signature]]?
| the `bbsSignature` using the `Sign` procedure of [[CFRG-Blind-BBS-Signature]] | |
| and [[CFRG-Pseudonym-BBS-Signature]], with appropriate key material, `bbsHeader` | |
| for the `header`, `bbsMessages` for the `messages`, and |commitment_with_proof| | |
| for the `commitment_with_proof`. If the signing procedure uses the optional | |
| |signer_blind| parameter retain this value for use when calling | |
| <a href="#serializebaseproofvalue"></a> below. | |
| This provides for the "pseudonym with hidden pid" feature. | |
| the `bbsSignature` using the `Sign` procedure of [[CFRG-Blind-BBS-Signature]] | |
| and [[CFRG-Pseudonym-BBS-Signature]], with appropriate key material, `bbsHeader` | |
| for `header`, `bbsMessages` for `messages`, and |commitment_with_proof| | |
| for `commitment_with_proof`. If the signing procedure uses the optional | |
| |signer_blind| parameter, retain this value for use when calling | |
| <a href="#serializebaseproofvalue"></a> (below). | |
| This provides for the "pseudonym with hidden pid" feature. |
There was a problem hiding this comment.
For now I'll put with the Pseudonym draft. If the Pseudonym draft gets absorbed into the Blind Signatures draft we can update.
There was a problem hiding this comment.
+1 to just go with what's there today (use "easiest" from above).
…unctuation, and formatting improvements. Co-authored-by: Ted Thibodeau Jr <[email protected]>
…di-bbs into pseudonyms-binding
index.html
Outdated
| @@ -596,7 +608,8 @@ <h4>parseBaseProofValue</h4> | |||
| disclosure base proof value. The required input is a proof value | |||
| (<var>proofValue</var>). A single object, <em>parsed base proof</em>, containing | |||
| five elements, using the names "bbsSignature", "bbsHeader", "publicKey", | |||
There was a problem hiding this comment.
| five elements, using the names "bbsSignature", "bbsHeader", "publicKey", | |
| three to five elements, using the names "bbsSignature", "bbsHeader", "publicKey", |
There was a problem hiding this comment.
I think this should be five (no pseudonym feature) or seven (pid and signer_blind present to signal pseudonym use, but possibly empty).
…provements for optional parameters Co-authored-by: Dave Longley <[email protected]>
…provements for optional parameters Co-authored-by: Ted Thibodeau Jr <[email protected]>
…provements for optional parameters Co-authored-by: Dave Longley <[email protected]>
… optional features.
Co-authored-by: Dave Longley <[email protected]> Co-authored-by: Ted Thibodeau Jr <[email protected]>
|
Normative, multiple reviews, changes requested and made, no objections, merging. |
|
I did end up merging this (even though it said this PR was closed and not merged), but had to do it manually because of a series of merge conflicts due to a non-rebased merge in this PRs history. @Wind4Greg we'll have to discuss how to avoid those sorts of things during our next sync call. |
This PR addresses issue #127 by showing how procedures can be modified to support the anonymous holder binding, pseudonyms with issuer known pid, and pseudonyms with hidden pid optional features based on emerging IETF/CFRG work. An outline of a section describing these features is provided.
Feedback is requested earlier rather than later to help improve this PR. Thanks ahead of time Greg.
Preview | Diff