AnonCreds are capable of all three features mentioned above.
Question: Should the items that are AnonCreds data models be included in this?
-This specification contains the cryptographic calculations necessary to produce +the data objects exchanged in using Hyperledger AnonCreds, and to verify the various proofs +embedded in those objects. The following is information about the notations used +in displaying the cryptographic calculations:
+a || b : Denotes the concatenation of octet strings a and b.
I \ J : For sets I and J, denotes the difference of the two sets i.e., all the elements of I that do not appear in J, in the same order as they were in I.
X[a..b] : Denotes a slice of the array X containing all elements from and including the value at index a until and including the value at index b. Note when this syntax is applied to an octet string, each element in the array X is assumed to be a single byte.
range(a, b) : For integers a and b, with a <= b, denotes the ascending ordered list of all integers between a and b inclusive (i.e., the integers i such that a <= i <= b).
length(input) : Takes as input either an array or an octet string. If the input is an array, returns the number of elements of the array. If the input is an octet string, returns the number of bytes of the inputted octet string.
H(...) : Any hash function.
Terms specific to pairing-friendly elliptic curves are:
+E1, E2 : elliptic curve groups defined over finite fields. This document assumes that E1 has a more compact representation than E2, i.e., because E1 is defined over a smaller field than E2.
G1, G2 : subgroups of E1 and E2 (respectively) having prime order r.
GT : a subgroup, of prime order r, of the multiplicative group of a field extension.
e : G1 x G2 -> GT a non-degenerate bilinear map.
r : The prime order of the G1 and G2 subgroups.
P1, P2 : points on G1 and G2 respectively. For a pairing-friendly curve, this document denotes operations in E1 and E2 in additive notation, i.e., P + Q denotes point addition and x * P denotes scalar multiplication. Operations in GT are written in multiplicative notation, i.e., a * b is field multiplication.
The following sequence diagram summarizes the setup operations performed by a Schema Publisher, the Issuer (one required and one optional) in preparing to issue an AnonCred credential based on provided Schema, and the one setup operation performed by each Holder. On successfully completing the operations, the Issuer is able to issue credentials based on the given Schema to the Holder. The subsections below the diagram detail each of these operations.
Those with a knowledge of DIDs might expect that in the flow above, the first +
Those with a knowledge of DIDs might expect that in the flow above, the first step would be for the issuer to publish a DID. However, in AnonCreds, DIDs are not used in the processing of credentials, and notably, the public keys used in AnonCreds signatures come not from DIDs, but rather from Credential Definition objects. DIDs may be used to identify the entity publishing the @@ -754,7 +757,7 @@
tail[index] = g_dash * (gamma ** index)
-Detailed process for tails file generation:
+Detailed process for tails file generation:
A gist of test value pairs can be found here.
-To enable broad interoperability, and to improve the security of AnonCreds by +
To enable broad interoperability, and to improve the security of AnonCreds by
eliminating the risk of malicious holders altering the raw data
values in hopes that the verifier will not check the encoding as part
of the overall presentation verification, future versions of AnonCreds
@@ -1266,7 +1269,7 @@
Once constructed, the issuer sends the credential to the holder for verification and storage.
-Please note the data attribute “birth_dateint” in the example above. The convention of +
Please note the data attribute “birth_dateint” in the example above. The convention of
putting a _dateint suffix on a credential attribute name is used to indicate
that the field contains a date in the form of an integer, such as “2022.11.21”
as the integer “20221121” (the number 20,221,121). By putting the date in that
@@ -1749,7 +1752,7 @@
restrictions item
in the presentation request, the holder MAY satisfy the presentation request
with self-attested attributes.
-To prevent confusion, the term “attribute” in this section always refers to +
To prevent confusion, the term “attribute” in this section always refers to
the required_attributes in a presentation request, and the term “claim” is
used for the data elements in a verifiable credential.
Often in discussions about verifiable presentations, the term “prover” +
Often in discussions about verifiable presentations, the term “prover”
is used to indicate the participant generating the presentation. Throughout the
Hyperledger AnonCreds implementation the term prover is used in the names of
methods performed by that participant. However, because in AnonCreds the holder and the prover are always the same entity, we’ll use holder to refer to the participant generating the requested presentation to
@@ -2367,7 +2370,7 @@
It is important for all verifiers to understand that the revealed attribute +
It is important for all verifiers to understand that the revealed attribute
proof (eq_proof described earlier) is a proof on the encoded value, not on
the raw value. As such, it is up to the verifier to know the “raw to encoded”
algorithm used by the issuer, and to verify that the revealed raw value properly
@@ -2507,7 +2510,7 @@
When Hyperledger Indy is the Verifiable Data Registry for the Revocation Registry Entry, the state is received from Indy ledger as the +
When Hyperledger Indy is the Verifiable Data Registry for the Revocation Registry Entry, the state is received from Indy ledger as the “deltas” (state changes) from either the initial state of the Registry or from a previous Revocation Registry Entry. While the older Indy version of AnonCreds used the “deltas” representation directly, the newer AnonCreds version @@ -3079,7 +3082,7 @@
The issuer MUST track of the revocation status of all of the +
The issuer MUST track of the revocation status of all of the
credentials within a RevReg so that it can both calculate the correct
accumulator and send to the VDR accurate lists (issued and revoked)
of the indices of the credentials whose status has changed since the last RevRegEntry was published. If the list and accumulator published to VDR get out of
@@ -3295,7 +3298,11 @@