Skip to content

Adding the "Credential" class #1057

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Adding the "Credential" class #1057

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 25 additions & 20 deletions vocab/credentials/v2/vocabulary.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,6 +33,11 @@ class:
label: Refresh service
comment: A Refresh Service is a mechanism that can be utilized by software agents to retrieve an updated copy of a Verifiable Credential.

- id: Credential
label: Credential
comment: |
A Credential is a set of one or more claims made by an issuer.
Copy link
Contributor

@OR13 OR13 Mar 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is proof one of these claims?

Copy link
Member Author

@iherman iherman Mar 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not specified as part of this vocabulary and, by default, yes, it can be a proof.

Never forget: a VerifiableCredential is also a Credential (that is what subclassing means).

Copy link
Contributor

@OR13 OR13 Mar 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see the subclass as defining any new information then... and it seems... not helpful.

It leads me to consider that both names are equally useful, and as such, we need only define 1.


- id: CredentialSchema
label: Credential schema
comment: A Credential Schema provides verifiers with enough information to determine if the provided data conforms to the provided schema.
Expand All @@ -45,56 +50,56 @@ class:
label: Credential evidence
comment: A Credential Evidence scheme provides enough information to a verifier to determine whether the evidence gathered meets their requirements for issuing a credential. The precise content of each evidence scheme is determined by the specific evidence type definition.

- id: CredentialGraph
label: (Verifiable) credential graph
comment: Instances of this class are RDF Graphs, where each of these graphs must include exactly one <a href="#Credential">Credential</a> (usually a <a href="#VerifiableCredential">Verifiable Credential</a>).
Copy link
Contributor

@OR13 OR13 Mar 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I strongly dislike the "usually" language here...

Copy link
Member Author

@iherman iherman Mar 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit the same question as for Presentation vs. VerifiablePresentation. Do we want to have a separate CredentialGraph and a VerifiableCredentialGraph? We do not know what the future holds, and I am tempted to define a CredentialGraph only, which is used to encapsulate a graph with a single Credential. Because a VerifiableCredential is also a Credential, this covers our current usage. Hence my choice in the naming.


- id: VerifiableCredential
label: Verifiable credential
comment: |
A Credential is a set of one or more claims made by an issuer. A Verifiable Credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable Credentials can be used to build Verifiable Presentations, which can also be cryptographically verified.

- id: VerifiableCredentialGraph
label: Verifiable credential graph
comment: Instances of this class are RDF Graphs, where each of these graphs must include exactly one Verifiable Credential
A Verifiable Credential is a <a href="#Credential">Credential</a> that is tamper-evident and has authorship that can be cryptographically verified. Verifiable Credentials can be used to build Verifiable Presentations, which can also be cryptographically verified.
Copy link
Contributor

@OR13 OR13 Mar 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like an improvement... but I note the conflict with https://github.com/w3c/vc-data-model/pull/1057/files#r1124649817

Copy link
Member Author

@iherman iherman Mar 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Conflict?

Copy link
Contributor

@OR13 OR13 Mar 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, more detail would have helped here...

Screen Shot 2023-03-10 at 4 43 10 PM

Are VerifiablePresentations made of Credentials?

Are VerifiablePresentations made of VerifiableCredentials?

Are Presentations made of VerifiableCredentials?

Are Presentations made of Credentials?

If a VerifiableCredential is a Credential, and a VerifiablePresentations is a Presentation....

These are the conflicts I mean....

The current spec defines "VerifiablePresentations" in terms of "VerifiableCredentials", you noted the confusion here:

Copy link
Member

@TallTed TallTed Mar 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whenever possible, when presenting text, please present it as text. It is difficult to read the screencap, and impossible to copy-and-paste from it, which is likely to be helpful in suggesting revisions (on either side of the flagged conflict).


- id: VerifiablePresentation
label: Verifiable presentation
comment: |
A Presentation is data derived from one or more Credentials, issued by one or more `issuers`, that is shared with a specific `verifier`. A Verifiable Presentation is a tamper-evident Presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Certain types of verifiable presentations might contain data that is synthesized from, but do not contain, the original verifiable credentials (for example, zero-knowledge proofs).
A Presentation is data derived from one or more <a href="#Credential">Credentials</a> (usually, but not necessarily, <a href="#VerifiableCredential">Verifiable Credentials</a>), issued by one or more `issuers`, that is shared with a specific `verifier`. A Verifiable Presentation is a tamper-evident Presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Certain types of verifiable presentations might contain data that is synthesized from, but do not contain, the original verifiable credentials (for example, zero-knowledge proofs).
Copy link
Contributor

@OR13 OR13 Mar 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is wrong, presentations are made from "VerifiableCredentials"... not "Credentials".

Screen Shot 2023-03-03 at 9 52 05 AM

Copy link
Member

@TallTed TallTed Mar 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[@OR13] This is wrong, presentations are made from "VerifiableCredentials"... not "Credentials".

The block you quoted (by screencap, which is rather hard to work with, and really should be copied-and-pasted text, still including the link to the original) speaks of VERIFIABLE presentations, not presentations.

PLEASE stop acting as if quite specific words and phrases (which were carefully and painfully arrived at, as I know from being a participant at the time) were meant to have less specific meaning, as I will continue to tell you, they were not, and your disingenuous quotations will only make the current process longer and more painful!

Copy link
Contributor

@OR13 OR13 Mar 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TallTed there is no RDF definition for "Presentation", and the section I am commenting on is regarding the id "VerifiablePresentation".

Copy link
Member Author

@iherman iherman Mar 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes indeed, I had to stop on how I would have to describe a VerifiablePresentation and, indeed, the "logical" approach is to refer to Verifiable Presentations only.

However. Do we have cases when a Presentation structure is used for Credentials only? If I encapsulate a Presentation in JWT with the proof left as external, I would indeed present a credential and not a Verifiable credential, right (I am not a JWT expert)? If so, do we want to go down the (painful) route of differentiating between a Presentation and a VerifiablePresentation? Isn't that an overkill? So I ended up doing what I did, as described in the PR description above.

Copy link
Member Author

@iherman iherman Mar 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forgot to say: it is a bit like in #1057 (comment) insofar as defining a Presentation that holds Credentials would cover all the use cases, because a VerifiableCredential is also a Credential. The only reason why I did not change the name to Presentation is because the term VerifiableCredential is already widely used, and a change of term name would create problems.

Copy link
Member

@brentzundel brentzundel Mar 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TallTed I do not agree that Orie is acting disingenuously. If you have concerns that WG members are acting in bad faith, the appropriate step is to contact the chairs for a conversation. Making accusations in github comments is not appropriate.


property:
- id: credentialSchema
label: Credential schema
domain: cred:VerifiableCredential
domain: cred:Credential
range: cred:CredentialSchema
comment: The value of the `credentialSchema` property MUST be one or more <a href="#CredentialSchema">Credential schema</a> instances.

- id: credentialStatus
label: Credential status
domain: cred:VerifiableCredential
domain: cred:Credential
range: cred:CredentialStatus
comment: The value of the `credentialStatus` property MUST be an instance of a <a href="#CredentialStatus">Credential status</a>.

- id: credentialSubject
label: Credential subject
domain: cred:VerifiableCredential
domain: cred:Credential
range: IRI
comment: An entity about which claims are made.

- id: evidence
label: Evidence
domain: cred:VerifiableCredential
domain: cred:Credential
range: cred:CredentialEvidence
comment: The value of the `evidence` property MUST be one or more <a href="#CredentialEvidence">Credential evidence</a> instances.

- id: expirationDate
label: Expiration date
domain: cred:VerifiableCredential
domain: cred:Credential
range: xsd:dateTime
deprecated: true
comment: The value of the `expirationDate` property was used to express the date and time the credential ceases to be valid. It has been deprecated in favor of <a href="#validUntil">`validUntil`</a>

- id: holder
label: Holder
domain:
- cred:VerifiableCredential
- cred:Credential
- cred:VerifiablePresentation
range : IRI
comment: |
Expand All @@ -110,21 +115,21 @@ property:

- id: issued
label: issue date
domain: cred:VerifiableCredential
domain: cred:Credential
range: xsd:dateTime
comment: |
The value of the `issued` property MUST be a string value of an ISO8601 combined date and time string representing the date and time the credential was issued. Note that this date represents the earliest date when the information associated with the <a href="#credentialSubject>`credentialSubject`</a> property became valid.

- id: issuer
label: issuer
domain: cred:VerifiableCredential
domain: cred:Credential
range: IRI
comment: |
The value of the `issuer` property MUST be a URI. It is RECOMMENDED that dereferencing the URI results in a document containing machine-readable information about the issuer that can be used to verify the information expressed in the credential.

- id: refreshService
label: refresh service
domain: cred:VerifiableCredential
domain: cred:Credential
range: cred:RefreshService
comment: The value of the `refreshService` property MUST be one or more Refresh Service instances such that the holder can refresh the credential.

Expand All @@ -136,26 +141,26 @@ property:

- id: termsOfUse
label: terms of use
domain: cred:VerifiableCredential,cred:VerifiablePresentation
domain: cred:Credential,cred:VerifiablePresentation
range: odrl:Policy
comment: |
If specified, the value of the optional `termsOfUse` property MUST specify one or more terms of use policies under which the issuer issued the credential or presentation. Each `termsOfUse` policy MUST specify its type (for example, `IssuerPolicy`) and MAY specify its instance `id`. The precise content of each term of use is determined by the specific `TermsOfUse` type definition. If the recipient (a holder or verifier) violates the specified terms of use, the responsibility is their own, and such violation may incur legal liability.

- id: validFrom
label: Valid from
domain: cred:VerifiableCredential
domain: cred:Credential
range: xsd:dateTime
comment: |
The value of the `validFrom` property MUST be a string value of an ISO8601 combined date and time string representing the date and time the credential was issued. Note that this date represents the earliest date when the information associated with the <a href="#credentialSubject>`credentialSubject`</a> property became valid.

- id: validUntil
label: Valid until
domain: cred:VerifiableCredential
domain: cred:Credential
range: xsd:dateTime
comment: The value of the `validUntil` property MUST be a string value of an ISO8601 combined date and time string representing the date and time the credential ceases to be valid.

- id: verifiableCredential
label: verifiable credential
domain: cred:VerifiablePresentation
range: cred:VerifiableCredentialGraph
comment: The value of the `verifiableCredential` property MUST identify a <a href="#VerifiableCredentialGraph">Verifiable credential graph</a> (informally, it indirectly identifies a <a href="#VerifiableCredential">Verifiable credential</a> contained in a separate graph).
range: cred:CredentialGraph
comment: The value of the `verifiableCredential` property MUST identify a <a href="#CredentialGraph">(Verifiable) credential graph</a> (informally, it indirectly identifies a <a href="#Credential">Credential</a> contained in a separate graph).