FCP: Delegatable credentials CDD scheme #14
Conversation
lovesh
requested review from
brentzundel,
danintel,
dcmiddle,
dhuseby,
dubovitskaya,
hartm,
mac-arrap,
manudrijvers,
mikelodder7 and
vaporos
as code owners
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. |
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. |
|
@danintel Resolved |
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.
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.
Yes, was a typo. Fixed.
Done |
There was a problem hiding this comment.
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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| - 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.
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.
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.
"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.
"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.
"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.
"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.
"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.
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.
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.
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.
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.
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.
Can you provide a hyperlink to Belenkiy?
There was a problem hiding this comment.
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. |
lovesh
force-pushed
the
delegatable_cdd
branch
from
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.
@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.
lovesh
changed the title
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>
lovesh
force-pushed
the
delegatable_cdd
branch
from
2d91ca6
to
4817683
Compare
Signed-off-by: lovesh lovesh.bond@gmail.com