Finalize - pending review - the terminolgy for the specification #193

swcurran · 2023-12-21T19:38:53Z

Signed-off-by: Stephen Curran [email protected]

Signed-off-by: Stephen Curran <[email protected]>

swcurran · 2023-12-21T19:42:10Z

Did a pass over the terminology to address the first part of #60. Once I have this done, as I pass through all of the spec docs (for a last pass review), I'll update the "ref"s.

Appreciate a review/approval/comments as I'd like this in place before the next step.

Thanks @TelegramSam @mikelodder7 and anyone willing/able to review. Perhaps @wip-abramson ?

Signed-off-by: Stephen Curran <[email protected]>

wip-abramson · 2024-01-02T15:09:20Z

spec/terminology.md


+~ A [cryptographic accumulator] is used space- and time-efficient method of proving a value membership is in a set of values without revealing the individual members of the set. In AnonCreds v1, an accumulator is a core element of the [[ref: verifiable credential]] revocation mechanism.


Suggested change

~ A [cryptographic accumulator] is used space- and time-efficient method of proving a value membership is in a set of values without revealing the individual members of the set. In AnonCreds v1, an accumulator is a core element of the [[ref: verifiable credential]] revocation mechanism.

~ A [cryptographic accumulator] is used as a space- and time-efficient method of proving a value membership in a set of values without revealing the individual members of the set. In AnonCreds v1, an accumulator is a core element of the [[ref: verifiable credential]] revocation mechanism.

I would be tempted to reference the type of accumulator used, but maybe this is the wrong place

What is the type of accumulator used? Do you know off-hand? I can check if needed.

Updated the text, and updated where the accumulator is used in AnonCreds — revocation.

It is an RSA based accumulator I believe, but I do not know the exact name offhand

wip-abramson · 2024-01-02T15:15:53Z

spec/terminology.md

+
+[[def: Blinded Secret, Blinded secret, blinded secret, unblinded secret, Unblinded secret]]
+
+~ A cryptographic technique where a secret value (a number) is blinded before it is shared such that the sender can later prove knowledge ("unblind") of the secret value. The AnonCreds v1.0 [[ref: link secret]]


Suggested change

~ A cryptographic technique where a secret value (a number) is blinded before it is shared such that the sender can later prove knowledge ("unblind") of the secret value. The AnonCreds v1.0 [[ref: link secret]]

~ A cryptographic technique where a secret value (a number) is blinded before it is shared such that the sender can later prove knowledge of the secret value. The AnonCreds v1.0 [[ref: link secret]]

This is not what I understand as ublinding. Unblinding is ther removal of the blinding factor from a signature over a blinded value. Such that you get a signature on the unblinded value.

I think just removing as I have suggested is okay.

Sounds good — thanks. Done.

wip-abramson · 2024-01-02T15:20:41Z

spec/terminology.md

+
+[[def: Blinding Factor, blinding factor]]
+
+~ A blinding factor is a random 3152 bit selected from the set of integers up to the order of the RSA group, `n`. It is generated by the [[ref:holder]] to blind the their [[ref:link secret]] during credential issuance. The blinding factor can then be removed from the signature the [[ref:issuer]] produces to retrieve a valid signature over the [[ref: unblinded link secret]]. A blinding factor is similarly generated for each non-disclosed attribute during credential presentation, such that a [[ref: holder]] can prove they know these values without revealing them to the [[ref: verifier]].


Suggested change

~ A blinding factor is a random 3152 bit selected from the set of integers up to the order of the RSA group, `n`. It is generated by the [[ref:holder]] to blind the their [[ref:link secret]] during credential issuance. The blinding factor can then be removed from the signature the [[ref:issuer]] produces to retrieve a valid signature over the [[ref: unblinded link secret]]. A blinding factor is similarly generated for each non-disclosed attribute during credential presentation, such that a [[ref: holder]] can prove they know these values without revealing them to the [[ref: verifier]].

~ A blinding factor is a random [[ref: BigNumber]] selected from the set of integers up to the order of the RSA group, `n`. It is generated by the [[ref:holder]] to blind their [[ref:link secret]] during credential issuance. Knowledge of the blinding factor can be used to create a [[ref: Blinded Secrets Correctness Proof]].The blinding factor can be removed from the signature the [[ref:issuer]] produces to retrieve a valid signature over the [[ref: unblinded link secret]]. A blinding factor and associated [[ref: Blinded Secrets Correctness Proof]] are similarly generated for each non-disclosed attribute during credential presentation, such that a [[ref: holder]] can prove they know these values without revealing them to the [[ref: verifier]].

Nice. Done.

wip-abramson · 2024-01-02T15:22:50Z

spec/terminology.md

+
+[[def: Call Home, Call home, call home]]
+
+~ Call home is a term used when evaluating the privacy characteristics of [[ref: verifiable credential]] deployments. If a [[ref: holder]] presenting data from a verifiable credential must always contact ("call home to") the [[ref: issuer]], [[ref: holder]] actions are open to the actual, or perception of, tracking of the holder by the issuer. [[ref: Verifiable credential]] schemes that do not make possible the tracking of [[ref: holder]] activities by [[ref: issuers]] are preferred.


Is it not also if a Verifier must call home to the issuer in order to verify each credential they are presented with?

It is of far less concern, I think. That a verifier uses a particular type of ID becomes known, but nothing about the holders they are verifying. Given the existing interaction between the issuer/holder, that is what enables tracking. A verifier would not be anything but an arbitrary verifier to the issuer. Its number of verifications would seem to be the most that could be tracked — with lots of techniques to get around that.

wip-abramson · 2024-01-02T15:28:39Z

spec/terminology.md

-~ A Credential Definition (also known as CRED_DEF or CLAIM_DEF) contains data required for [[ref: credential]] issuance (used by the [[ref:issuer]]) as well as [[ref: credential]] validation data (used by the [[ref:holder]] and the [[ref:verifier]]). A Credential Definition is generated by the [[ref:issuer]] before [[ref:credential]] issuance and consists of two distinct but strongly related parts, the **Public Credential Definition** and **Private Credential Definition**.
+[[def: Credential Definition, Credential Definitions, Public Credential Definition, Private Credential Definition, CredDef, CredDefs, credential definition, CLAIM_DEF, CRED_DEF]]
+
+~ A credential definition (also known as CRED_DEF or CLAIM_DEF) contains data required for [[ref: credential]] issuance (used by the [[ref:issuer]]) as well as [[ref: credential]] validation data (used by the [[ref:holder]] and the [[ref:verifier]]). A credential definition is generated by the [[ref:issuer]] before [[ref:credential]] issuance and consists of two distinct but strongly related parts, the **Public Credential Definition** that is published for everyone to use and **Private Credential Definition** that is held as a secret by the issuer and has the private keys necessary to generate signed [[ref: verifiable credentials]]. A credential definition may be generated such that credentials it produces can be revoked.


Interesting. I always thought that CRED_DEF refers to only the public part. Here seems to be saying it is both the public and private parts.

The “private” data of a Cred Def is just the corresponding data to the public parts, so doesn’t seem to be worth splitting up.

wip-abramson · 2024-01-02T15:33:14Z

spec/terminology.md

+
+[[def: Credential Key Correctness Proof]]
+
+~ A proof generated during the creation of the [[ref: credential definition]] and included in the [[ref: credential offer]] so that the [[ref:holder]] can verify that the published [[ref: credential definition]] used in the blinding process belongs to the [[ref:issuer]].


Suggested change

~ A proof generated during the creation of the [[ref: credential definition]] and included in the [[ref: credential offer]] so that the [[ref:holder]] can verify that the published [[ref: credential definition]] used in the blinding process belongs to the [[ref:issuer]].

~ A proof generated during the creation of the [[ref: credential definition]] and included in the [[ref: credential offer]] so that the [[ref:holder]] can verify that the [[ref: issuer]] is in control of the private data associated with the published [[ref: credential definition]].

Yeah see, this makes me thing that credential definition should be public. Then there is some other defined term for the private part.

OK - fair enough. I’ll try a reword...

wip-abramson · 2024-01-02T15:39:57Z

spec/terminology.md


-~ Revokable Verifiable Credentials require (besides) a Credential Definition also a [[ref: REV_REG_DEF]].
+~ A credential request is a request from an [[ref: holder]] towards a [[ref: issuer]] to get a credential issued by the [[ref: issuer]]. The credential request references a preceding [[ref: credential offer]] and defines the claims the [[ref: holder]] wants to get issued. A credential request also includes a [[ref: nonce]] that is later to use the issuance of the credential.


Suggested change

~ A credential request is a request from an [[ref: holder]] towards a [[ref: issuer]] to get a credential issued by the [[ref: issuer]]. The credential request references a preceding [[ref: credential offer]] and defines the claims the [[ref: holder]] wants to get issued. A credential request also includes a [[ref: nonce]] that is later to use the issuance of the credential.

~ A credential request is a request from an [[ref: holder]] towards a [[ref: issuer]] to get a credential issued by the [[ref: issuer]]. The credential request references a preceding [[ref: credential offer]] and defines the claims the [[ref: holder]] wants to get issued, including a [[ref: Blinded Secret]] and associated [[ref: Blinded Secrets Correctness Proof]]. A credential request also includes a [[ref: nonce]] that is later to use the issuance of the credential.

wip-abramson · 2024-01-02T15:42:14Z

spec/terminology.md

-
-[[def: issuer, issuers]]
+
+~ A Decentralized Identifier (DID), defined by the [W3C DID Core Specification](https://w3c.github.io/did-core/), is a type of identifier that is useful in enabling verifiable, decentralized digital identity. A DID refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID. DIDs are not used in AnonCreds itself but there must be a verifiable identifier (usually a DID) with an enforced relationship between [[ref: schema publishers]] and [[ref: issuers]] and the AnonCreds objects they publish. This is outlined in a note in [this specification section](#anoncreds-setup-data-flow).


In some earlier instances you defined the links serparetly. Do we want to continue that for the DID core link?

E.g. BigNumber is like this

Good catch — aligned to use the one link definition.

wip-abramson · 2024-01-02T15:46:06Z

spec/terminology.md

+
+[[def: DID Method, DID method, DID Methods, DID methods]]
+
+~ DID methods specify how DID documents are written (registered) and read (resolved) on a given [[ref: verifiable data registry]] implementation, allowing DIDs to be registered and resolved in a wide variety of storage containers. The capabilities required by DID Methods are defined in the [DID Core specification], and the (many) DID Methods are defined in the [DID Methods Registry] repository.


Suggested change

~ DID methods specify how DID documents are written (registered) and read (resolved) on a given [[ref: verifiable data registry]] implementation, allowing DIDs to be registered and resolved in a wide variety of storage containers. The capabilities required by DID Methods are defined in the [DID Core specification], and the (many) DID Methods are defined in the [DID Methods Registry] repository.

~ DID methods specify how DID documents are created and read (resolved) on a given [[ref: verifiable data registry]] implementation, allowing DIDs to be registered and resolved in a wide variety of storage containers. The capabilities required by DID Methods are defined in the [DID Core specification], and the (many) DID Methods are defined in the [DID Methods Registry] repository.

Suggested change

~ DID methods specify how DID documents are written (registered) and read (resolved) on a given [[ref: verifiable data registry]] implementation, allowing DIDs to be registered and resolved in a wide variety of storage containers. The capabilities required by DID Methods are defined in the [DID Core specification], and the (many) DID Methods are defined in the [DID Methods Registry] repository.

~ DID methods specify how DID documents are written (registered) and read (resolved) on a given [[ref: verifiable data registry]] implementation, allowing DIDs to be created and resolved in a wide variety of storage containers. The capabilities required by DID Methods are defined in the [DID Core specification], and the (many) DID Methods are defined in the [DID Methods Registry] repository.

A DID document does not always have to be registered to be valid. E.g. did:key. I think created aligns better with DID spec

wip-abramson

Okay I had a pass at it and left a bunch of comments. Hopefully they are useful

Signed-off-by: Stephen Curran <[email protected]>

spec/terminology.md

TelegramSam · 2024-01-05T04:45:54Z

a few comments added

Signed-off-by: Stephen Curran <[email protected]>

swcurran · 2024-01-05T15:58:00Z

Thanks @TelegramSam — ready for re-review.

Finalize - pending review - the terminolgy for the specification

e50b1ce

Signed-off-by: Stephen Curran <[email protected]>

swcurran requested review from TelegramSam and mikelodder7 December 21, 2023 19:39

Convert any typo def: links to be ref: in non-terminology files

df527dc

Signed-off-by: Stephen Curran <[email protected]>

This was referenced Dec 21, 2023

Rationalize the terminology "def"s and the "ref"s in the rest of the spec #60

Closed

Change nomenclature in section 7. Terminology #77

Closed

Clarified holder as software vs person/org, separated prover def

7c8d06a

Signed-off-by: Stephen Curran <[email protected]>

swcurran mentioned this pull request Dec 21, 2023

Ambiguity of "holder" makes the spec inconsistent #100

Open

wip-abramson reviewed Jan 2, 2024

View reviewed changes

Updated based on comments

814d252

Signed-off-by: Stephen Curran <[email protected]>

TelegramSam reviewed Jan 5, 2024

View reviewed changes

spec/terminology.md Outdated Show resolved Hide resolved

TelegramSam reviewed Jan 5, 2024

View reviewed changes

spec/terminology.md Outdated Show resolved Hide resolved

Updates based on feedback

36819f7

Signed-off-by: Stephen Curran <[email protected]>

TelegramSam approved these changes Jan 5, 2024

View reviewed changes

swcurran merged commit fe4383d into hyperledger:main Jan 5, 2024
1 check passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Finalize - pending review - the terminolgy for the specification #193

Finalize - pending review - the terminolgy for the specification #193

swcurran commented Dec 21, 2023

swcurran commented Dec 21, 2023

wip-abramson Jan 2, 2024

wip-abramson Jan 2, 2024

swcurran Jan 2, 2024

swcurran Jan 2, 2024

wip-abramson Jan 2, 2024

wip-abramson Jan 2, 2024

swcurran Jan 2, 2024

wip-abramson Jan 2, 2024

swcurran Jan 2, 2024

wip-abramson Jan 2, 2024

swcurran Jan 2, 2024

wip-abramson Jan 2, 2024

swcurran Jan 2, 2024

swcurran Jan 2, 2024

wip-abramson Jan 2, 2024

wip-abramson Jan 2, 2024

swcurran Jan 2, 2024

wip-abramson Jan 2, 2024

wip-abramson Jan 2, 2024

swcurran Jan 2, 2024

wip-abramson Jan 2, 2024

swcurran Jan 2, 2024

wip-abramson left a comment

TelegramSam commented Jan 5, 2024

swcurran commented Jan 5, 2024


		~ A [cryptographic accumulator] is used space- and time-efficient method of proving a value membership is in a set of values without revealing the individual members of the set. In AnonCreds v1, an accumulator is a core element of the [[ref: verifiable credential]] revocation mechanism.


		[[def: Blinded Secret, Blinded secret, blinded secret, unblinded secret, Unblinded secret]]

		~ A cryptographic technique where a secret value (a number) is blinded before it is shared such that the sender can later prove knowledge ("unblind") of the secret value. The AnonCreds v1.0 [[ref: link secret]]

-~ A cryptographic technique where a secret value (a number) is blinded before it is shared such that the sender can later prove knowledge ("unblind") of the secret value. The AnonCreds v1.0 [[ref: link secret]]
+~ A cryptographic technique where a secret value (a number) is blinded before it is shared such that the sender can later prove knowledge of the secret value. The AnonCreds v1.0 [[ref: link secret]]
+This is not what I understand as ublinding. Unblinding is ther removal of the blinding factor from a signature over a blinded value. Such that you get a signature on the unblinded value.
+I think just removing as I have suggested is okay.


		[[def: Blinding Factor, blinding factor]]

		~ A blinding factor is a random 3152 bit selected from the set of integers up to the order of the RSA group, `n`. It is generated by the [[ref:holder]] to blind the their [[ref:link secret]] during credential issuance. The blinding factor can then be removed from the signature the [[ref:issuer]] produces to retrieve a valid signature over the [[ref: unblinded link secret]]. A blinding factor is similarly generated for each non-disclosed attribute during credential presentation, such that a [[ref: holder]] can prove they know these values without revealing them to the [[ref: verifier]].


		[[def: Call Home, Call home, call home]]

		~ Call home is a term used when evaluating the privacy characteristics of [[ref: verifiable credential]] deployments. If a [[ref: holder]] presenting data from a verifiable credential must always contact ("call home to") the [[ref: issuer]], [[ref: holder]] actions are open to the actual, or perception of, tracking of the holder by the issuer. [[ref: Verifiable credential]] schemes that do not make possible the tracking of [[ref: holder]] activities by [[ref: issuers]] are preferred.


		[[def: Credential Key Correctness Proof]]

		~ A proof generated during the creation of the [[ref: credential definition]] and included in the [[ref: credential offer]] so that the [[ref:holder]] can verify that the published [[ref: credential definition]] used in the blinding process belongs to the [[ref:issuer]].


		~ Revokable Verifiable Credentials require (besides) a Credential Definition also a [[ref: REV_REG_DEF]].
		~ A credential request is a request from an [[ref: holder]] towards a [[ref: issuer]] to get a credential issued by the [[ref: issuer]]. The credential request references a preceding [[ref: credential offer]] and defines the claims the [[ref: holder]] wants to get issued. A credential request also includes a [[ref: nonce]] that is later to use the issuance of the credential.


		[[def: issuer, issuers]]

		~ A Decentralized Identifier (DID), defined by the [W3C DID Core Specification](https://w3c.github.io/did-core/), is a type of identifier that is useful in enabling verifiable, decentralized digital identity. A DID refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID. DIDs are not used in AnonCreds itself but there must be a verifiable identifier (usually a DID) with an enforced relationship between [[ref: schema publishers]] and [[ref: issuers]] and the AnonCreds objects they publish. This is outlined in a note in [this specification section](#anoncreds-setup-data-flow).


		[[def: DID Method, DID method, DID Methods, DID methods]]

		~ DID methods specify how DID documents are written (registered) and read (resolved) on a given [[ref: verifiable data registry]] implementation, allowing DIDs to be registered and resolved in a wide variety of storage containers. The capabilities required by DID Methods are defined in the [DID Core specification], and the (many) DID Methods are defined in the [DID Methods Registry] repository.

Finalize - pending review - the terminolgy for the specification #193

Finalize - pending review - the terminolgy for the specification #193

Conversation

swcurran commented Dec 21, 2023

swcurran commented Dec 21, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wip-abramson left a comment

Choose a reason for hiding this comment

TelegramSam commented Jan 5, 2024

swcurran commented Jan 5, 2024