Skip to content

Structured Credential Data Model and Business Rules [was Bound and Unbound Credentials] #788

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 2 commits into from
Closed

Structured Credential Data Model and Business Rules [was Bound and Unbound Credentials] #788

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3d9716f
Buound and Unbound Credentials
mwherman2000 Aug 6, 2021
426adb6
Bound and Unbound Credentials
mwherman2000 Aug 6, 2021
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
49 changes: 48 additions & 1 deletion index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -128,6 +128,8 @@
enable us to travel between countries. This specification provides a mechanism
to express these sorts of <a>credentials</a> on the Web in a way that is
cryptographically secure, privacy respecting, and machine-verifiable.
Credentials can also be used to represent business documents such as purchase orders,
invoices, waybills, and delivery confirmations.
</p>
</section>

Expand Down Expand Up @@ -213,6 +215,11 @@ <h2>Introduction</h2>
continues to be elusive.
</p>

<p>
Credentials can also be used to represent business documents such as purchase orders,
invoices, waybills, and delivery confirmations.
</p>

<p>
Currently it is difficult to express education qualifications, healthcare
data, financial account details, and other sorts of third-party <a>verified</a>
Expand Down Expand Up @@ -281,6 +288,9 @@ <h3>What is a Verifiable Credential?</h3>
Information related to constraints on the credential (for example, expiration
date, or terms of use).
</li>
<li>
Information used to describe all types of business documents (for example, purchase orders, invoices, waybills, and delivery confirmations)
</li>
</ul>

<p>
Expand All @@ -291,7 +301,18 @@ <h3>What is a Verifiable Credential?</h3>
</p>

<p>
<a>Holders</a> of <a>verifiable credentials</a> can generate
There are 2 broad categories of <a>verifiable credentials</a>: <a>bound credentials</a> and <a>unbound credentials</a>.
Copy link
Member

Choose a reason for hiding this comment

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

I'm concerned about adding new classes of verifiable credential. We tried hard to reduce the amount of new terminology that people would need to learn to use VCs and I'm not sure the addition of this distinction is helpful. I think it might be harmful.

That is not to say that the concept doesn't exist. It does, and we should document it. I just don't think we should give it a misleading name.

Copy link
Author

@mwherman2000 mwherman2000 Aug 10, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

I'm concerned about adding new classes of verifiable credential. We tried hard to reduce the amount of new terminology that people would need to learn to use VCs and I'm not sure the addition of this distinction is helpful. I think it might be harmful.

That is not to say that the concept doesn't exist. It does, and we should document it. I just don't think we should give it a misleading name.

@msporny I think you're missing a key point in this discussion: @swcurran and I have stumbled on the need/requirement for a more formal taxonomic approach to describing the different species and subspecies of credentials. After you learn more about these concepts, I think you'll #seethelight (aka #seetheproof).

#788 (comment) is just the tip of the #credentialberg ;-) :-)

<a>Bound credentials</a> are bound a specific credential <a>subject</a>.
Copy link
Member

@TallTed TallTed Aug 27, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

PRs require some adherence to the language in which they're ostensibly written. Some expansion of what you mean by "[not] bound to a subject". VCs contain subject-predicate-object (triple) statements; they do not contain key-value pairs. Thus, it seems that your "unbound credentials" are not VCs, and as such, they don't belong in the VC Data Model, nor anywhere in the VC universe -- unless perhaps as "anti-examples"...

Suggested change
<a>Bound credentials</a> are bound a specific credential <a>subject</a>.
<a>Bound credentials</a> are bound to a specific credential <a>subject</a>.

<a>Unbound credentials</a> are not bound to a <a>subject</a>.
As such, <a>unbound credentials</a> cannot be used to create <a>verifiable presentations</a> -
they are simply "data that has been signed by an <a>Issuer</a> and held by any <a>Holder</a>".
<a>Unbound credentials</a> are easily issued to and exchanged between groups of two or more <a>Holders</a>.
The most common use case for <a>unbound credentials</a> is to represent
all types of business documents like invoices and purchase orders
(that are not simple extensions or representations of a single subject).
Comment on lines +310 to +312
Copy link
Member

Choose a reason for hiding this comment

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

Hrm, disagree with this language. Business documents, invoices, and purchase orders typically have identifiers associated with them that would be the credentialSubject identifier.

Copy link
Member

Choose a reason for hiding this comment

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

Also, a given VC is not necessarily about a single subject!


<p>
<a>Holders</a> of <a>bound verifiable credentials</a> can generate
<a>verifiable presentations</a> and then share these
<a>verifiable presentations</a> with <a>verifiers</a> to prove they possess
<a>verifiable credentials</a> with certain characteristics.
Expand Down Expand Up @@ -871,6 +892,32 @@ <h3>Presentations</h3>

</section>

<section class="informative">
<h3>Bound Credentials and Unbound Credentials</h3>

<p>
There are 2 broad categories of <a>verifiable credentials</a>: <a>bound credentials</a> and <a>unbound credentials</a>.
<a>Bound credentials</a> are bound a specific credential <a>subject</a>.
<a>Unbound credentials</a> are not bound to a <a>subject</a>.
As such, <a>unbound credentials</a> cannot be used to create <a>verifiable presentations</a> -
they are simply "data that has been signed by an <a>Issuer</a> and held by any <a>Holder</a>".
<a>Unbound credentials</a> are easily issued to and exchanged between groups of two or more <a>Holders</a>.
The most common use case for <a>unbound credentials</a> is to represent all types of business documents like invoices and purchase orders
(that are not simple extensions or representations of a single subject).
</p>
<p>
<a>Bound credentials</a> contain a <a>subject</a> id element inside the credentialSubject element
(which binds the credential to a subject and enables the <a>Holder</a> of the <a>credentential</a>
to derive <a>verifiable presentations</a> from the <a>bound credential</a>).
Comment on lines +910 to +911
Copy link
Member

Choose a reason for hiding this comment

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

This characterization is problematic, while it's true, it gives the impression that this is the only use of the credentialSubject.id property, which it isn't. The credentialSubject.id is also useful to identify a particular node in a graph of information.

</p>
<p>
<a>Unbound credentials</a> do not contain a <a>subject</a> id element inside the credentialSubject element.
An <a>unbound credential</a> is "like signed data issued to a <a>Holder</a>".
Copy link
Member

Choose a reason for hiding this comment

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

I don't know what this sentence means. When describing concepts, we should avoid using quotes that could be misinterpreted.

Copy link
Author

Choose a reason for hiding this comment

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

I don't know what this sentence means. When describing concepts, we should avoid using quotes that could be misinterpreted.

Don't get lost in the prose (yes, I realize this is a PR to the spec). As I indicated above (or is it below), I see a major restructuring of the credential spec and there's at least of few of us interested in tackling it now. To reduce confusion, I'm going to call this new characterization Structured Credentials (a term I've already started to use and have an implementation of. Reference: https://www.youtube.com/watch?v=KXhyvKXCLus&list=PLU-rWqHm5p45dzXF2LJZjuNVJrOUR6DaD&index=1).

Copy link
Member

Choose a reason for hiding this comment

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

The prose is all we have to understand your meaning. It is in all of our best interests to write as clearly as we can, and to elaborate and clarify wherever it is made plain that our writing -- our prose -- is not clearly communicating our meaning.

A specific <a>unbound credential</a> can be held by 2 more <a>Holders</a> at the same time. For example, an invoice
Copy link
Member

Choose a reason for hiding this comment

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

This is true for any sort of VC, not just unbound credentials. Any credential can be held by more than one Holder at any given time. Some VCs can be bound to the credentialSubject.id at presentation time. This language needs to be tightened up so that it won't confuse people reading the specification.

can be held simulataneously by a supplier and a purchaser - including multiple parties at each of the supplier and purchaser
organizations.
</p>

<section class="informative">
<h3>Concrete Lifecycle Example</h3>

Expand Down