-
Notifications
You must be signed in to change notification settings - Fork 17
FCP: Delegatable credentials CDD scheme #14
FCP: Delegatable credentials CDD scheme #14
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you define verkey
in the text?
The directory name is misspelled: s/deegatable_cdd/delegatable_cdd/
Also see comments for 2 typos.
text/deegatable_cdd/README.md
Outdated
|
||
Most of the implemented logic follows the paper with the corrections called out in the code. | ||
At several places, computations like e(a, b)<sup>c</sup> have been replaced with e(a<sup>c</sup>, b) since they are about 30% faster. Attempts are made to replace computations in G2 with computations in G1 inside pairings. | ||
Regarding the implementation of `verify_fast` function, it applies this observation to pairings: if it needs to be cheched that a == b and c == d and e == f, then choose a random number `r` and check whether (a-b) + (c-d)\*r + (e-f)\*r<sup>2</sup> == 0. This is because this degree 2 polynomial can have at most 2 roots and if r is not a root then all the coefficients must be 0. If r is a randomly chosen element from a sufficiently large set, then the chances of r being a root are negligible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/cheched/checked/
text/deegatable_cdd/README.md
Outdated
// OR for Groth2 | ||
let sig: Groth2Sig = Groth2Sig::new(msgs.as_slice(), &sk2, ¶ms2)?; | ||
``` | ||
- An existing signature can be randomized by calling `randomize` on the siganture with a randomly chosen field element. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/siganture/signature/
@danintel Resolved |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am having trouble reviewing (and suggesting changes) due to the excessive length of many of the lines.
Please select a maximum line length (perhaps 80 characters or so) and re-format.
text/delegatable_cdd/README.md
Outdated
# Guide-level explanation | ||
[guide-level-explanation]: #guide-level-explanation | ||
|
||
The entity delegating the credential issuance rights and identified to the verifier is called the *root issuer* or the *root delegator*. All issuers have a signing and verification key but only the root issuer's verification key is known to the verifier. The linear structure starting at the root issuer and consisting of subsequent issuers involved in delegation is called the *issuer chain*. For reasons explained later, an issuer is either an odd level issuer or an even level issuer depending on its position in the issuer chain. The *root issuer* is always an even level issuer. Similarly, the linear structure starting at the root issuer's credential and consisting of subsequent issuers' credentials is called the *credential chain*. A credential is either an odd level credential or even level credential depending on the issuer; an even level issuer always issues an even level credential and vice versa. Each credentials in the credential chain is a also called a *link* and has a level which is a monotonically increasing number starting from 1 and has no gaps. The credential (or link) issued by root issuer has level 1, the subsequent link will have level 2 and so on. During delegation (credential issuance), the delegator in addition to issuing a credential, sends its credential chain also to the delgatee. A presentation created from the delegated credential is called *attribute token*. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I read this correctly:
- the root issuer is always an even level issuer
- an even level issuer always issues an even level credential
- The credential issued by the root issuer has level 1
This seems off.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, was a typo. Fixed.
Done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Completed review.
I've suggested numerous editorial changes.
I wonder at the need for a user to differentiate between whether they are an even-level vs. an odd-level issuer. That feels like a potential source for confusion, but perhaps this isn't the level at which such considerations ought to be made.
text/delegatable_cdd/README.md
Outdated
Blockchain](https://acmccs.github.io/papers/p683-camenischA.pdf) by Camenisch | ||
et.al. This allows issuers to delegate issuance rights to other entities such | ||
that the presentations from their issued credentials do not reveal their | ||
identity but only the identity of the the first issuer in the delegation chain. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
identity but only the identity of the the first issuer in the delegation chain. | |
identites but only the identity of the the first issuer in the delegation chain. |
text/delegatable_cdd/README.md
Outdated
the credential chain is a also called a *link* and has a level which is a | ||
monotonically increasing number starting from 1 and has no gaps. The credential | ||
(or link) issued by root issuer has level 1, the subsequent link will have level | ||
2 and so on. During delegation (credential issuance), the delegator in addition |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2 and so on. During delegation (credential issuance), the delegator in addition | |
2, and so on. During delegation (credential issuance), the delegator, in addition |
text/delegatable_cdd/README.md
Outdated
to issuing a credential, sends its credential chain also to the delgatee. A | ||
presentation created from the delegated credential is called *attribute token*. | ||
|
||
Because verification keys of even level issuers is cryptographically different |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because verification keys of even level issuers is cryptographically different | |
Because the verification keys of even-level issuers are cryptographically different |
text/delegatable_cdd/README.md
Outdated
presentation created from the delegated credential is called *attribute token*. | ||
|
||
Because verification keys of even level issuers is cryptographically different | ||
from verification keys of odd level issuers, verification key of even level |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from verification keys of odd level issuers, verification key of even level | |
from the verification keys of odd-level issuers, the verification keys of even-level |
text/delegatable_cdd/README.md
Outdated
|
||
Because verification keys of even level issuers is cryptographically different | ||
from verification keys of odd level issuers, verification key of even level | ||
issuers is called even level verification key and of odd level issuers is called |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issuers is called even level verification key and of odd level issuers is called | |
issuers are called even-level verification keys and those of odd-level issuers are called |
text/delegatable_cdd/README.md
Outdated
# Drawbacks | ||
[drawbacks]: #drawbacks | ||
|
||
This solution should not be used when privacy among issuers is desired. Secondly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This solution should not be used when privacy among issuers is desired. Secondly | |
This solution should not be used when privacy among issuers is desired. Secondly, |
text/delegatable_cdd/README.md
Outdated
# Rationale and alternatives | ||
[alternatives]: #alternatives | ||
|
||
An expensive alternative of delegatable credentials is the holder to get |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An expensive alternative of delegatable credentials is the holder to get | |
An expensive alternative to delegatable credentials is for each holder to get a |
text/delegatable_cdd/README.md
Outdated
There are some alternatives which offer privacy among issuers as well but have | ||
different tradeoffs. [Delegatable Attribute-based Anonymous Credentials from | ||
Dynamically Malleable Signatures](https://eprint.iacr.org/2018/340) requires | ||
presence of a trusted third party. [Delegatable Anonymous Credentials from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
presence of a trusted third party. [Delegatable Anonymous Credentials from | |
the presence of a trusted third party. [Delegatable Anonymous Credentials from |
text/delegatable_cdd/README.md
Outdated
Dynamically Malleable Signatures](https://eprint.iacr.org/2018/340) requires | ||
presence of a trusted third party. [Delegatable Anonymous Credentials from | ||
Mercurial Signatures](https://eprint.iacr.org/2018/923) does not support | ||
credential with attributes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
credential with attributes. | |
credentials with attributes. |
text/delegatable_cdd/README.md
Outdated
# Unresolved questions | ||
[unresolved]: #unresolved-questions | ||
|
||
- Its expected that the API can be more refined like does it make sense to use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Its expected that the API can be more refined like does it make sense to use | |
- It is expected that the API can be more refined, e.g., it may make sense to use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Completed review.
I've suggested numerous editorial changes.
I wonder at the need for a user to differentiate between whether they are an even-level vs. an odd-level issuer. That feels like a potential source for confusion, but perhaps this isn't the level at which such considerations ought to be made.
The caller code should sufficiently hide the odd/even details. In the issuance protocol, when the credential is being requested, the requester would know at what level the issuer is and the requester's code will thus choose the appropriate keys. |
text/delegatable_cdd/README.md
Outdated
delegate the issuance rights to its subordinates, then the credential receivers | ||
can check that credential comes from a delegatee of the head. In addition, | ||
delegation provides privacy to issuers who might want to remain anonymous to | ||
verifiers. This [Aries RFC](https://github.com/hyperledger/aries-rfcs/pull/218) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please update this link to: https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0104-delegatable-credentials (the PR has now been merged).
text/delegatable_cdd/README.md
Outdated
consisting of subsequent issuers involved in delegation is called the *issuer | ||
chain*. For reasons explained later, an issuer is either an odd-level issuer or | ||
an even-level issuer depending on its position in the issuer chain. The *root | ||
issuer* is always an even-level issuer. Similarly, the linear structure starting |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"is always an even-level issuer" --> "is always an even-level issuer, since it occupies index 0 in the chain."
text/delegatable_cdd/README.md
Outdated
at the root issuer's credential and consisting of subsequent issuers' | ||
credentials is called the *credential chain*. A credential is either an odd | ||
level credential or even-level credential depending on the issuer; an even-level | ||
issuer always issues an odd-level credential and vice versa. Each credentials in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Each credentials" --> "Each credential"
text/delegatable_cdd/README.md
Outdated
credentials is called the *credential chain*. A credential is either an odd | ||
level credential or even-level credential depending on the issuer; an even-level | ||
issuer always issues an odd-level credential and vice versa. Each credentials in | ||
the credential chain is a also called a *link* and has a level which is a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"is a also called" --> "is also called"
text/delegatable_cdd/README.md
Outdated
issuer always issues an odd-level credential and vice versa. Each credentials in | ||
the credential chain is a also called a *link* and has a level which is a | ||
monotonically increasing number starting from 1 with no gaps. The credential | ||
(or link) issued by the root issuer has level 1, the subsequent link will have level |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"issued by the root issuer has level 1" --> "issued by the root issuer has level 1, conferring on the downstream recipient an odd-level status" (I'm trying to clarify that the level of a credential is associated with the level of its holder, not the level of its issuer)
text/delegatable_cdd/README.md
Outdated
(or link) issued by the root issuer has level 1, the subsequent link will have level | ||
2, and so on. During delegation (credential issuance), the delegator, in addition | ||
to issuing a credential, sends its credential chain also to the delegatee. A | ||
presentation created from the delegated credential is called *attribute token*. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"is called attribute token" --> "is called an attribute token"
This term feels awkward to me. The presentation may contain many attributes, not just one--correct? If so, perhaps a better name would be "attributes token" (plural) or "token of attributes" or "token of presented attributes" or "presentation token".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The term "attribute token" comes from the paper, I will mention this in the doc as well. I agree that it's not an obvious term and "presentation" or "proof" sounds better. How do folks feel about deviating a bit in terminology? @hartm @manudrijvers @dubovitskaya @dcmiddle @khovratovich
signing and verification key but only the root issuer's verification key is | ||
known to the verifier. The linear structure starting at the root issuer and | ||
consisting of subsequent issuers involved in delegation is called the *issuer | ||
chain*. For reasons explained later, an issuer is either an odd-level issuer or |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please link to the later explanation about structure-preserving cryptography; you use the concept so heavily, so early in the doc, that people may feel the need to look up your reasoning before they arrive at the explanation organically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The last paragraph of the tutorial section explained the reasoning but i converted it to a sub-section and mentioned here that the perplexed reader can jump to it. Does this work?
The reason for this distinction of odd and even levels is the use of *structure | ||
preserving cryptography*. A cryptographic scheme is called structure preserving | ||
if its all public inputs and outputs consist of group elements of bilinear | ||
groups and the functional correctness can be verified only by computing group |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you are quoting, you should put quotes around the sentence and give a hyperlink to your source.
The reason for this distinction of odd and even levels is the use of *structure | ||
preserving cryptography*. A cryptographic scheme is called structure preserving | ||
if its all public inputs and outputs consist of group elements of bilinear | ||
groups and the functional correctness can be verified only by computing group |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be nice if you inserted a sentence somewhere near here, in which you clarify that, although the even/odd distinction is necessary to the underlying crypto, it is likely to be entirely hidden from users by intervening implementation.
text/delegatable_cdd/README.md
Outdated
[prior-art]: #prior-art | ||
|
||
Delegatable anonymous credentials have been explored since the last decade and | ||
the first efficient (somewhat) came in 2009 by Belenkiy et al. in "Randomizable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you provide a hyperlink to Belenkiy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you are quoting, you should put quotes around the sentence and give a hyperlink to your source.
I will put quotes. I have a link in the footnote form but I now realize that github does not display it nicely like my editor. Will change.
I left a few comments about the mechanics of the doc, but I wanted to note that I am very eager for this to be merged. Aries RFC 0104 depends on this underlying mechanism--and that RFC in turn is the basis of some guardianship solutions that are being built right now. The sooner Ursa has support for this, the better. |
082d9f0
to
8f811c8
Compare
Is there any reason we cannot merge this now? |
text/delegatable_cdd/README.md
Outdated
At several places, computations like e(a, b)<sup>c</sup> have been replaced with | ||
e(a<sup>c</sup>, b) since they are about 30% faster. Attempts are made to | ||
replace computations in G2 with computations in G1 inside pairings. | ||
Regarding the implementation of `verify_fast` function, it applies this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hartm @khovratovich @manudrijvers @dubovitskaya This is an implementation level optimization which was not in the paper so i wanted to check with you guys that it is fine. @hartm reviewed it and found it ok.
Signed-off-by: lovesh <lovesh.bond@gmail.com>
Signed-off-by: lovesh <lovesh.bond@gmail.com>
…y of verify_fast Signed-off-by: lovesh <lovesh.bond@gmail.com>
…e clarifications Signed-off-by: lovesh <lovesh.bond@gmail.com>
Signed-off-by: lovesh <lovesh.bond@gmail.com>
Signed-off-by: lovesh <lovesh.bond@gmail.com>
Signed-off-by: lovesh <lovesh.bond@gmail.com>
2d91ca6
to
4817683
Compare
Signed-off-by: lovesh lovesh.bond@gmail.com