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

[mwherman2000]

This PR documents the existence of and difference between Bound Credentials and Unbound Credentials. No fundamental changes are needed to support these 2 broad categories of (Verifiable) Credentials.

NOTE: Bearer Credentials are a more purpose-specific specialization of the more general-purpose concept of Unbound Credentials.

---

Preview | Diff

[agropper]

This seems unadvised. See decentralized-identity/edv-spec#65 (comment)

[mwherman2000]

This seems unadvised. See decentralized-identity/edv-spec#65 (comment)

Why? I don't find it reasonable to throw in a comment like the above without a full explanation @agropper

What are your specific issue(s) with https://github.com/w3c/vc-data-model/pull/788/files?

[mwherman2000]

A more detailed discussion can be found here: decentralized-identity/edv-spec#65 (comment)

[kdenhartog]

Noting first that there's an IPR flag that needs to be addressed. I'm leaning more towards this is a substantive contribution due to the affects it would have on the current reading about subjects and holders of verifiable credentials. @iherman what's your take on this from an IPR perspective?

If it is considered a substantive change then we'll need to achieve consensus on the topic which would mean this needs to be deferred to V1.2 or V2 which are currently not in scope of the maintenance working group.

[mwherman2000]

@kdenhartog @iherman With respect to the IPR issue, thank you for bringing this to my attention. I have completed the application to hopefully resolve this: https://www.w3.org/ieapp/3344

[mwherman2000]

@kdenhartog To be transparent, as much as I would like to see Unbound Credentials added to the specification itself, the primary purpose of this PR is simply to shed new light/understanding on what is already in the VC data model specification. That is, this PR requires no changes to the VC data model itself, the elements of a VC, nor the semantics of the current set of VC elements.
Bottom line: Does this PR belong in the specification? ...or is it a new significant use case (i.e. an application of the current VC data model)?

[UPDATE] With the presence of Bearer Credentials in the current spec, Unbound Credentials should be defined in the spec as the more general construct from which Bearer Credentials are derived. See #788 (comment)

[David-Chadwick]

The VC data model already has the concept of unbound credentials. They are called bearer credentials. Therefore I do not support the addition of the term unbound credentials to the VC data model. Furthermore I also see no reason why this type of credential cannot be included in a VP.

[mwherman2000]

Thank you for the pointer @David-Chadwick : https://w3c.github.io/vc-data-model/#bearer-credentials. With respect to your comment...

The VC data model already has the concept of unbound credentials. They are called bearer credentials.

the detailed semantics are important here.

While Unbound Credentials and Bearer Credentials appear to be similar, Unbound Credentials are generalization of the more purpose-specific concept of Bearer Credentials. Unbound Credentials are a more general construction; Bearer Credentials carry a lot of additional baggage, like ...

While bearer credentials can be privacy-enhancing, they must be carefully crafted so as not accidentally divulge more information than the holder of the bearer credential expects. For example, repeated use of the same bearer credential across multiple sites enables these sites to potentially collude to unduly track or correlate the holder. Likewise, information that might seem non-identifying, such as a birthdate and postal code, can be used to statistically identify an individual when used together in the same bearer credential or session.

None of the above applies to the more general concept of Unbound Credentials. Think of using Unbound Credentials for defining the RGB colors for specific color names, purchase orders, waybills, delivery conformations, etc. Here's a specific Unbound Credential example (not subject to any of the Bearer Credential baggage):

{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "did:colors:primarycolors",
    "type": ["VerifiableCredential", "ColorPalette"],
    "credentialSubject": {
      "colors": [
          "red",
          "green",
          "blue"
      ]
    },
    "proof": { ... }
  }

[David-Chadwick]

@mwherman2000 I beg to differ with you. If you replace the adjective bearer with unbound the sentences still read perfectly well and apply to unbound just as they do to bearer ones. There is no need for the new concept as it is not more generic than the existing concept.

[brentzundel]

Speaking as the WG Chair: though the changes are arguably editorial, as they do not add or remove normative language, they do introduce a new conceptual framing for verifiable credentials, which I feel reflects a substantive change.
The VCWG is currently in maintenance mode, which means that the only substantive changes we can make to the specification must be in response to bugs. We can only fix things, not add new things. Until such point as this working group is no longer in maintenance mode, I don't anticipate spending meeting time on any PR not related to v1.1 or v1.2 of the spec.

I encourage @mwherman2000 to raise an issue where this topic can be discussed by interested folks until such time as it can be taken up by a re-chartered VCWG.

[mwherman2000]

I encourage @mwherman2000 to raise an issue where this topic can be discussed by interested folks until such time as it can be taken up by a re-chartered VCWG.

1. @brentzundel Understood. In fact, most of the substantive discussion is already taking place here (not ideal but c'est la vie): [PROPOSAL] EDV documents should be Unbound Credentials (from a document format perspective). Why create a new or different format? decentralized-identity/edv-spec#65

2. @brentzundel @kdenhartog Without investing too much time/energy, do you think Unbound Credentials might best fit into: a) the specification or b) as a VC use case? Given that Unbound Credentials are an application/interpretation of the current normative language, are Unbound Credentials better addressed as a VC use case? (reference: Structured Credential Data Model and Business Rules [was Bound and Unbound Credentials] #788 (comment)) @swcurran?

[swcurran]

I think the conversation is the EDV group has veered in another direction, so would like to raise the topic for discussion here, since it is the same discussion and this is where it should happen.

The big issue for us is not so much "Bound" and "Unbound" as terms, but the role (or lack thereof) of the holder in the VC 1.0 Data Model. The spec. seems to minimize the role of the holder such that despite appearing in the canonical image at the start of the spec, is only referenced in the JSON-LD data model examples in the Appendix.

Here is (a slightly modified version of) my comment from the EDV repo on this topic:

The concept of bound and unbound VCs stems for a world view difference about the participants in the VC trust triangle, and that I (at least) think exposes a crucial weakness in the VC 1.0 Data Model. We think the bound/unbound concept might be a way to allow for both views to be supported without a radical change to the spec. But the real question is about the holder.

Background: As we in Aries have moved from using only Indy AnonCreds to adding support for the W3C VC standard, we've discovered a huge difference in the cryptographic trust model between the two. In the AnonCreds model, the holder is always a cryptographic component of the Trust Triangle, while in the W3C VC model, it is usually not. In AnonCreds, the Issuer MUST include in the verifiable credential a proof about the Holder on issuance, and the verifier MUST verify the verifiable presentation comes from the intended Holder. In the VC model, there is no such required binding to the Holder -- evidently anyone can hold an issued VC and present it. You can bind it to the holder (and we think many would) but it is not required and in fact, barely discussed in the spec.

Adding the concept of Bound (as in AnonCreds) and Unbound (as in W3C VC Spec.) VCs could clarify support for both models.

• Unbound: The Issuer issued a claim that a verifier can verify. "Alice said the Sky is Blue"
• Bound: The Issuer made a claim to the Holder that a verifier can verify both the claim and that it was made to the holder. "Alice said to Carol that the Sky is Blue"

Of course, while cryptographic proof is included in both models, the verifier must still make their human trust decision -- do they trust the issuer? The Bound model allows the verifier to use the cryptographic proof to have confidence in the holder, tying that confidence based on the verifier's trust that the issuer only issues to intended holders.

Section 5.1 of the W3C V3 Spec. is quite jarring for those that assume the Holder is a core participant in the model. That a VC can be transferred freely amongst holders is, well, quite stunning to those of us with that view.

Basically, all of our use cases (and all that we can think of) require the concept that the Issuer issues the verifiable credential to the Holder and only that Holder can present a proof based on that verifiable credential. We see far less value for credentials that do not include the holder as a cryptographic participant.

The bearer token is the only obvious example of an unbound VC, but it should not be the (I would argue very limited) use case that removes the importance of the holder for the many other use cases in the spec.

[mwherman2000]

@swcurran @brentzundel @kdenhartog First, I need to acknowledge that it was Stephen who reached out to me in side conversation last week that inspired the discovery and documentation of this new specie of credential called Unbound Credentials.

Second, I believe the categorization of credentials into Bound and Unbound Credentials is a fundamental discovery. How fundamental? To a large extent, these are the only 2 things that need to be described in the Verifiable Credentials Data Model specification: Bound and Unbound Credentials (plus other subspecie like Bearer Credentials). We're talking about a fundamental rewrite of the data model spec.

Third, the rewrite will totally and fundamentally change the landscape of the specification. For example, the VC triangle diagram is no longer a fundamental element of the specification because the diagram is no longer an all encompassing concept in terms of what VCs are and how they are used. What happens to the VC triangle? I'm afraid to inform you that the VC triangle gets relegated to being just another VC use case. Yes, it will be the biggest elephant in the VC use case document but it becomes just another use case nether the less.

@msporny This also has fundamental implications for the VC HTTP API specification: https://w3c-ccg.github.io/vc-http-api/

[mwherman2000]

For completeness (to document the new specie), I've attached the following diagrams. A video narration is being uploaded.

Bound and Unbound Credentials

Narration: https://youtu.be/KXhyvKXCLus?t=1030

Primary Colors: Unbound Credential Example

Narration: https://youtu.be/KXhyvKXCLus?t=1187

[msporny]

In general, +1 to describing that 1) you can use VCs for things like invoices, waybills, and delivery confiramtions, and 2) when to include a credentialSubject.id and when not to and what that means.

In general, -1 to introducing a new term to talk about the concept as we're trying to reduce (not increase) the number of terms one needs to understand in order to understand the technology. That is, we're trying to reduce #cliquespeak, not increase it... and every new unnecessary term we introduce to the specification increases #cliquespeak.

[msporny]

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.

[mwherman2000]

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 ;-) :-)

[msporny]

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

[TallTed]

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

[msporny]

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.

[msporny]

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

[mwherman2000]

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).

[TallTed]

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.

[msporny]

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.

[msporny]

@mwherman2000 wrote:

We're talking about a fundamental rewrite of the data model spec.

Oof, well I was with you on this being Editorial until I read that.

To be clear, I don't think this is a fundamental change to the VC spec (as @David-Chadwick noted, this concept has always existed in the specification, people have implemented "unbound" VCs just fine per the current spec, and it doesn't fundamentally change anything in the spec as far as I can tell). More documentation is good, which is why I was supportive of some variation of this PR as an Editorial thing.

However, now that @swcurran and @mwherman2000 are noting that this is a fundamental change to the VC data model (again, which I disagree with), it'll require far more discussion and time allocated to consensus-building than we can give it in a v1.1 or even a v1.2 release. This is a v2.0 discussion if we're contemplating a "fundamental rewrite of the data model spec".

I'll wait for a response from both @mwherman2000 and @swcurran before marking it as such.

[swcurran]

Well this took an interesting turn. I have a completely different desire for a change to the spec to that which @mwherman2000 is looking. My concern is exactly what @msporny states above -- "Any credential can be held by more than one Holder at any given time." That makes (per @mwherman2000 's terminology) all of them unbound. To me, references to "unbound VCs" abound in the spec., but there is almost nothing about "bound VCs", and that's a problem.

What I'm looking for is much more emphasis on the Holder and that there be references to how the Holder be bound in the VC. In other words that Figure 1 from the spec. actually be followed. That the issuer issues the VC to a specific holder, and only the holder be able to provide a verifiable presentation accepted by the verifier.

The literal Figure 1 version of the trust triangle is core to the Indy AnonCreds model, and yet is not explicitly mentioned in the W3C VC Spec. In AnonCreds a VC cannot be transferred to another Holder, and we think that is extremely powerful. In the vast, vast majority of our use cases, it is crucial that the verifier know the VC was issued to the entity presenting it.

[dlongley]

@swcurran,

In AnonCreds a VC cannot be transferred to another Holder, and we think that is extremely powerful.

Can this be clarified a little bit? What does it mean to say that it "cannot be transferred"? What does "transfer" mean in this context and how does it work with the definition of holder in the spec today? How would this sort of thing be turned into normative, testable language in a data model specification?

Depending on the language, there may be concerns around enforceability. I think the intent to prevent transfer can be expressed but unless there is correlation (the credentials and presentations are fully "linkable"), it's really just a plea. This makes expressing that intent potentially dangerous if verifiers misinterpret it as enforceable. Perhaps the language could be editorial and focus on linkability and how verifiers can require proofs in presentations around the identifier(s) that establish the link(s).

[msporny]

@swcurran wrote:

To me, references to "unbound VCs" abound in the spec., but there is almost nothing about "bound VCs", and that's a problem.

Thanks for the clarification @swcurran. For the sake of simplicity, let's treat your request and @mwherman2000's request as separate issues. I assume that you have read the sections on the Credential Subject, Proofs, Validation of the CredentialSubject, Subject-Holder Relationships and didn't find that any of those sections addressed your concerns:

https://w3c.github.io/vc-data-model/#presentations-0 (Holder property)
https://w3c.github.io/vc-data-model/#credential-subject-0 (How to validate holder)
https://w3c.github.io/vc-data-model/#subject-holder-relationships (Various types of Subject-Holder relationships -- though I personally disagree with some of the content in that appendix)

We can always do a better job at documentation. Do you have something pithy that we could add to the specification that would address your concerns? I'll note that there are a number of use cases that don't take the Aries requirement of strongly bound VCs/presentations... ones that have very large deployment targets -- https://www.businesswire.com/news/home/20210511005386/en/NACS-Announces-TruAge%E2%84%A2-Digital-ID-Verification-Solution

[swcurran]

From @dlongley: Can this be clarified a little bit? What does it mean to say that it "cannot be transferred"? What does "transfer" mean in this context and how does it work with the definition of holder in the spec today? How would this sort of thing be turned into normative, testable language in a data model specification?

Meaning that the issuer inserts into the AnonCreds credential a binding to the holder. In AnonCreds today it is the blinded link secret, but it could be a DID. Either way, proof of control of the mechanism must be demonstrated as part of the verifiable presentation.

[dlongley]

@swcurran,

Either way, proof of control of the mechanism must be demonstrated as part of the verifiable presentation.

Yeah, in that case, I'd think someone could draw up some editorial language that can focus on linkability and how verifiers can require proofs in presentations around the identifier(s) that establish the link(s) -- and what the guarantees are/aren't or what the trade offs are with that approach.

[swcurran]

@msporny -- I definitely reviewed those sections and they solidified my view that the spec. has little focus on the role of the holder, despite it's inclusion in Figure 1. There is little normative text about the holder, and as noted above, "holder" is only in the JSON-LD example in the Appendix. The view that "Anyone can hold any VC and prove it to a verifier" comes through loud and clear in the spec -- which is my concern. We think that's a big issue -- that in many cases the verifier would really like to know the binding of the VC to the holder. They want to know if the issuer explicitly issued the VC to the holder. If the verifier trusts the issuer, that could include that the issuer had a reason to issue the VC to the holder.

Taking it further, what if the emphasis of the spec. shifted to the holder (as presented in Figure 1), and the question of what the VC was about was left to the semantics of the VC defined by the issuer? In other words, reduce the emphasis on "subject" in the core spec. Obviously, the holder = subject is easily handled, since the holder is known. However, the holder != subject is easily covered by the semantics of the issued VC. Where the holder is irrelevant, the holder binding is left off, allowing the VC to be held by any holder.

That view is probably a bridge too far in the VC 1.x spec. Adding a section about being explicit about a proof of the binding between the holder and VC would be a big help.

I would be interested to know how many people in the community think that a VP can only come from the holder to which the VC was explicitly issued.

Glad to hear more, @msporny, about the NACS use case -- there is not enough in the article about the technical solution.

[mwherman2000]

I'll reply later today. First, my IPR issue has been resolved but I need my laptop to properly fix it here.

With respect to "boundedness", I think where @swcurran and I cooperatively differ is that I'm defining/scoping boundedness strictly from the values of the data elements of the credential itself. I think what @swcurran is focused on is holdedness in a Holder's Agent's wallet ...which is understandably different.

[mwherman2000]

In general, -1 to introducing a new term to talk about the concept as we're trying to reduce (not increase) the number of terms one needs to understand in order to understand the technology. That is, we're trying to reduce #cliquespeak, not increase it... and every new unnecessary term we introduce to the specification increases #cliquespeak.

@msporny Creating new thoughtful terminology is not #cliquespeak. However, attempting to corral or, otherwise, trying to circumvent or limit a conversation is #cliquespeak in one of is worse forms. Here's the current definition of #cliquespeak...

Reference: https://hyperonomy.com/2019/04/09/clique-speak/

[andrewhughes3000]

A general question, not directed at any particular contribution/contributor... In the non-W3 world of 'credentials, licenses and permits' does the following hold? At credential issuance time: * an issuer identifies and authenticates a credential applicant (who is or is not the subject of the eventual credential) * the issuer creates what some call a 'binding record' in their system that records details like the identifiers of the applicant, the credential and maybe something about the target device/credential storage system * the issuer encodes this 'binding record' information inside the credential, or it does not At presentation time: * the credential verifier cares or does not care that the presenter of the credential/presentation is authorized to present it (regardless of their status as Subject or not-Subject) * if the verifier cares, then they use a) their own rules to determine if the presenter is the holder is the subject? OR b) use the issuer's rules for the same? OR c) use the Holder's rules (c obviously doesn't make sense) I'm trying to point out that the so-called bound/binding topic refers to a record held at the Issuer. This might be embedded in the credential or it might not be. At the end of the day, the Verifier may want to understand what the Issuer intended at issuance - is the credential only presentable by the Subject? presentable by the Holder? presentable on behalf of another Subject? and so on. The Verifier needs those facts in order to make decisions about whether to accept the credential presentation from the entity actively presenting it at transaction time. Something similar is probably needed for the credential storage app (aka Wallet) so that it respects the authorization semantics. Is any of the above relevant to this thread? andrew. *Andrew Hughes *CISM CISSP *In Turn Information Management Consulting* o +1 650.209.7542 m +1 250.888.9474 5043 Del Monte Ave., Victoria, BC V8Y 1W9 ***@***.*** *https://www.linkedin.com/in/andrew-hughes-682058a <https://www.linkedin.com/in/andrew-hughes-682058a>* *Digital Identity | International Standards | Information Security *

…

On Tue, Aug 10, 2021 at 4:41 PM Michael Herman (Trusted Digital Web) < ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In index.html <#788 (comment)>: > + <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>). + </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>". 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 ). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#788 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AETAZ7HEL2FPMGJ25JBG7ETT4G2JVANCNFSM5BVUEUTQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[msporny]

@msporny Creating new thoughtful terminology is not #cliquespeak.

Hmm, that's interesting.

I'd argue that new thoughtful terminology can be categorized as #cliquespeak... per the definition of #cliquespeak -- "any type of speech that seeks to limit conversations to a select group of insiders" ... I mean, even uttering the words "Verifiable Credentials" is #cliquespeak, no? Any new definition does that, doesn't it? So, can't we just assert that everything is #cliquespeak since it's subjective; in the eye of the beholder? ... and if everything even remotely controversial can be #cliquespeak, is it really that useful of a concept?

Then again, I note that you're the one who invented the word and defined it on your blog, so you get to use it (and redefine it) however you choose, which is (in itself) #cliquespeak.

However, attempting to corral or, otherwise, trying to circumvent or limit a conversation is #cliquespeak in one of is worse forms.

Ah, so I can't disagree with your position w/o being accused of #cliquespeak ... I see.

Well, go ahead then, I'll just stop engaging (with you in this particular PR).

I look forward to seeing your initiative to convince the VCWG that what we need is "a fundamental rewrite of the data model spec."

[msporny]

@swcurran wrote:

The view that "Anyone can hold any VC and prove it to a verifier" comes through loud and clear in the spec -- which is my concern.

If that's the take-away, that's certainly an issue.

That view is probably a bridge too far in the VC 1.x spec.

I think I get what you're saying, and yes, that might be a bridge too far w/o a healthy amount of debate (that we could open back up during the upcoming VCWG recharter).

Adding a section about being explicit about a proof of the binding between the holder and VC would be a big help.

Agreed, would you mind taking a first cut and trying to draft a PR for that, @swcurran?

I would be interested to know how many people in the community think that a VP can only come from the holder to which the VC was explicitly issued.

It would be a good polling item, agreed. We may want to see if @vsnt would like to add that in an upcoming community poll?

@swcurran -- would you mind creating an issue to track this concern? At present, it only lives in this PR.

[mwherman2000]

@msporny Creating new thoughtful terminology is not #cliquespeak.

Hmm, that's interesting.

@msporny You do not understand #cliquespeak. Have you read the "10 real-life examples" in blog article? Here they are:

10 Real-Life Examples of #CliqueSpeak

1. “…it’s not like we’re considering any of those topics for the first time.”
2. “We may want to limit discussion if people that are new to the work, such as yourself, insist on rehashing things that we’ve already discussed.”
3. “I know it will take time for you to trust that we’re trying to do the right thing for the community, Web, and Internet in general.”
4. “Unfortunately, trust of that level takes months to years to develop and regular interaction and demonstrating over time that we have the best interests of the community at heart is all we can do to make you believe that we’re trying to do the right thing here.”
5. “There are things that have strong consensus, such as dereferencing a DID gives you a DID Document.”
6. “It’s incredibly difficult to navigate all of that if you haven’t been a part of the community since it’s beginning…”
7. “There are discussions that keep coming up repeatedly that many in the community have explored multiple times and so rehashing those discussions is not useful if there is consensus on the topic.”
8. “We’ve been having these topical discussions for a few years now and we’re probably through most of them.”
9. “We need to be careful to not retread territory that we’ve already covered.”
10. “You are also potentially re-opening discussions that we have consensus on, so we need to be careful not to do that because if we do that, lots of decisions that were finalized end up being reopened and we’ll waste a tremendous amount of time coming back to the same conclusion we came to many months/years ago.”

These are the definitive real-life examples of CCG #cliquespeak.

[mwherman2000]

With respect to "boundedness", I think where @swcurran and I cooperatively differ is that I'm defining/scoping boundedness strictly from the values of the data elements of the credential itself. I think what @swcurran is focused on is holdedness in a Holder's Agent's wallet ...which is understandably different.

Here's is a first cut at the taxonomy I was alluding to early ...it's a first crack at a specification framework for the next version of the Verifiable Credentials (or independent Structured Credentials) specification...

The above is based on different levels or combinations of "boundedness" ...and not "holdedness" (see above).

Then applications and processes like the VC triangle flow become use cases or more elaborate application notes. Business rules like @swcurran 's for when a verifiable credential can legitimately be used to generate a verifiable presentation (VP) can then be attached to specific nodes in the above taxonomy. Ditto for business documents like POs, invoices, waybills, and delivery confirmations, etc.

[mwherman2000]

Structured Credential Data Model

Structured Credential Business Rules

Actors and Roles

A1.1. A Holder is a Role.
A1.2. An Issuer is a Role.
A1.3. A Verifier is a Role.
A2.1. An Originator is a Subrole of the Holder Role.
A2.2. A Recipient is a Subrole of the Holder Role.
A3. An Actor can be a specific Person, Organization, or Thing. An example of an Actor is Alice.
A4. An Actor can be assigned to one or more Roles. As an example, Alice can be assigned the Holder Role.

Credential Taxonomy

T1. Different types of Structure Credentials are categorized into 4 top-level Structured Credential Families. Named Verifiable Credential (NVC) is an example of a Structured Credential Family.
T2. A Structured Credential Family is further categorized into Structured Credential Species. Named Verifiable Unbound Credential (NVC Unbound Credential) is an example of a Structured Credential Species.
T3. A Structured Credential Species is further categorized into Structured Credential Subspecies. A Named Verifiable (Unbound) Bearer Credential is an example of a Structured Credential Subspecies.

Agents

G1. To participate in the Structured Credential ecosystem, an Actor has an Agent, a software service. For example, in Alice's role as a Holder, Alice has an Agent.
G2. Specifically, Actors assigned the Holder Role (including the Originator and Recipient Subroles) have an Agent.
G3. Specifically, Actors assigned the Issuer Role have an Agent.
G4. Specifically, Actors assigned the Verifier Role have an Agent.

Wallets (Structured Credential Storage)

W1. An Actor's Agent has a Wallet, a secure repository for storing Structured Credentials (Credential Repository). For example, in Alice's role as a Holder, Alice's Agent has a Wallet for storing Structured Credentials.
W2. A Wallet can be used to store any of the 4 Structured Credentials Families of Structured Credentials.

Subledgers

S1. Optionally, a Wallet can have Subledgers.
S2, Optionally, a Subledger can have a collection of (sub) Subledgers.
S3. Optionally, a Subledger can be used to organize and store collections of Structured Credentials.

Business Rules

Business Rules: General

R1. Structured Credential Business Rules determine what actions are available to be performed on a particular set of Structured Credential Species (or Subspecies) based on a set of Structured Credential Preconditions. Examples of a Structured Storage Preconditions are:

1. Structured Credential Family, Species, and/or Subspecies of the Structured Credential
2. Which Roles a particular Actor is assigned to (e.g. Holder)
3. Whether the Structured Credential's Subject (credentialSubject id) is specified (or not)
4. Whether the Structured Credential's Subject (credentialSubject id) is equal to one of the Holder's id's

Business Rules: Issuing a Verifiable Credential

IVC1. To Issue a Verifiable Credential, the following Structured Credential Preconditions must be satisfied:

0. Izzy is an Actor
1. Izzy has a Public-Private Key Pair (KP)
2. Izzy is assigned an Issuer Role (aka Izzy's Issuer Persona)
3. As an Issuer, Izzy has an Agent A and A has a Wallet W (aka Credential Repository)
4. A is capable of receiving, validating, and accepting incoming Credential Requests (e.g. from Alice in Alice's Holder Role), creating new Verifiable Credentials (containing a Verifiable Proof), and transferring Verifiable Credentials to the Requesting Holder's Agent (the final step in Issuing a Verifiable Credential)
5. Izzy has a personal Identifier I associated with Izzy's Issuer Persona (aka Issuer Role) - typically a DID but not necessarily
6. The credentialSubject id of the new Verifiable Credential VC has the same value as the id of the Requesting Holder's Persona
7. VC needs to have a credential id (CI) with a non-empty value - typically a DID but not necessarily
8. VC needs to have a Proof P that is based on Alice's Public-Private Key Pair KP
9. P is Verifiable - based on Alice's Public Key that is associated with KP
10. W is used by Izzy's Agent to store incoming Credential Requests as well as in-process Structured Credentials (before, during, and, possibly, after VC has been Issued) in Izzy's role as an Issuer.

Business Rules: Creating a Verifiable Presentation

P1. For Actor Alice to be able to create a Verifiable Presentation VP from a Verifiable Credential VC, the following Structured Credential Preconditions must be satisfied:

0. Alice is an Actor
1. Alice has a Public-Private Key Pair (KP)
2. Alice is assigned a Holder Role (aka Alice's Holder Persona)
3. As a Holder, Alice has an Agent A and A has a Wallet W (aka Credential Repository)
4. Alice needs to hold Verifiable Credential VC in Alice's Wallet
5. Alice has a personal Identifier I associated with Alice's Holder Persona (aka Holder Role) - typically a DID but not necessarily
6. The credentialSubject id of VC has the same value as Alice's Identifier I
7. VC needs to have a credential id (CI) with a non-empty value - typically a DID but not necessarily
8. VC needs to have a Proof P that is based on Alice's Public-Private Key Pair KP
9. P is Verifiable - based on Alice's Public Key that is associated with KP

Business Rules: Creating a NVC Unbound Credential (e.g. Invoice Business Document)

BD1. An Actor in an Issuer Role may be used but is not required to create nor transfer an NVC Unbound Credential.
BD2. An Actor in the Holder Subrole of Originator can create and transfer an NVC Unbound Credential.
BD3. By definition, an NVC Unbound Credential (e.g. complex business documents like Purchase Orders, Invoices, Waybills, and Delivery Confirmations) does not contain a credentialSubject id.
BD4. A common NVC Unbound Credential use case is representing a collection of Claims that do not represent an extension of a Subject's Digital Identity (Digital Identifier plus associated Digital Identity Data) or Credentials equally associated with multiple Parties (Subjects). An Invoice and a Purchase Order are common examples.

[David-Chadwick]

@andrewhughes " if the verifier cares, then they use a) ... OR b) use the issuer's rules for the same?" Hi Andrew this is why the non-transferable property was defined in section C.1.1, for the issuer to assert that the presentation must be made by the credential subject otherwise it is invalid. However there was insufficient agreement in the group to standardise this property, so it remains non-normative. That does not negate its importance, since many plastic cards contain this property today. Kind regards David

[kdenhartog]

We discussed this on the call and believe that the larger work of conceptual reworking the spec isn't within scope of the maintainence working group. The scope of what @swcurran seems like it could fall as an only editorial change within this and should be addressed in a separate PR.

[agropper]

Thanks @andrewhughes3000 for your comment.

As I see it, VCs stand on their own in the same way a physical (driver's license) credential is verifiable on its own. Protocols associated with a driver's license do not presume any particular Holder but there are some assumptions such as a size that fits in a wallet and that verification will include a biometric match by a natural person.

On top of this simple equivalence between human and machine verification, W3C and DIF have built an extensive mythology that makes room for:

• Selective disclosure of individual attributes of a VC
• Combining VCs issued to linked pseudonyms
• Zero-Knowledge Proofs of a VC

These features could be implemented by giving every VC it's own "smartphone" with connectivity, a secure element and local biometrics and maintain the "stand alone" characteristic of a physical (driver's license) credential. However none of us want to carry a dozen or a few hundred phones, no matter how slim and cheap they may be. Impractical.

So, the idea has been that the VC is just a data model and a single connected secure element with local biometrics would "Hold" any number of VCs and control their presentation. Practical.

The practical alternative does not change the fundamental fact that a Verifier has to trust the Issuer and their practices. If a VC and its presentations do not include local biometrics as part of the verification process, then things get complicated and there's a major risk that Issuers and Verifiers will insist on "certifying" the Holder functionality for their own convenience. Part of this complication is that Holder is a role, just like Issuer and Verifier, whereas the issuance and verification protocols have to deal with things.

My point is that VCs and their presentation do not depend on the inclusion of a Holder role. Any consent mechanism that can process a request into a verifiable credential or presentation (note the lower case) could deliver selective disclosure, linked pseudonyms and ZKPs. All of various consent mechanisms process requests, but some respond with verifiable data structures while others respond with access tokens that can be used to access a verifiable data structure.

Whether an Issuer becomes aware that a VC has been accessed by a particular Verifier is important, so the request / consent protocols must give the consenting party a choice of hiding the use of a VC from the Issuer if that is important in a particular context.

[mwherman2000]

@swcurran Given your world view Stephen, what are the Preconditions for an Actor Alice to be able to create a Verifiable Presentation VP from a Verifiable Credential VC?

For example, which (or all) of the following Preconditions are necessary for an Actor Alice to be able to create a Verifiable Presentation VP from a Verifiable Credential VC?

0. Alice is an Actor
1. Alice has a Public-Private Key Pair (KP)
2. Alice is assigned a Holder Role (aka Alice's Holder Persona)
3. As a Holder, Alice has an Agent A and A has a Wallet W (aka Credential Repository)
4. Alice needs to hold Verifiable Credential VC in Alice's Wallet
5. Alice has a personal Identifier I associated with Alice's Holder Persona (aka Holder Role) - typically a DID but not necessarily
6. The credentialSubject id of VC has the same value as Alice's Identifier I
7. VC needs to have a credential id (CI) with a non-empty value - typically a DID but not necessarily
8. VC needs to have a Proof P that is based on Alice's Public-Private Key Pair KP
9. P is Verifiable - based on Alice's Public Key that is associated with KP

NOTE: Refresh this page. I've changed this posting at least 10 times.

[iherman]

The issue was discussed in a meeting on 2021-08-11

• no resolutions were taken

View the transcript

3.1. Structured Credential Data Model and Business Rules [was Bound and Unbound Credentials] (pr vc-data-model#788)

See github pull request #788.

Kyle Den Hartog: I've looked at this and think this is may be editorial.

Manu Sporny: I let my feelings be known on the issue. what seems to be suggested is a fairly significant re-write.
… we need to explain the concepts, but the approach is confusing
… two things: Stephen's request is reasonable and I've asked him to put in an issue for it
… Michael's is more involved than v1.1

Kyle Den Hartog: Just want to clarify here - I think technically speaking this can already be addressed with no normative statements. I think its possible to describe purchase orders as an editorial only change. If we go for Michael's larger conceptual change it's definitely necessary to move to V2

Brent Zundel: I noted in the issue, from my perspective as a Chair, though the language introduced to the spec doesn't change any normative changes, it does substantively change the specification. I don't think it's in scope in v1.1 Maintenance at all. The overarching thematic introduction of these new ideas in this way is a substantive change and should be deferred to a v2.

Kyle Den Hartog: wanted to clarify, the larger conceptual things are V2, but the idea of not having a holder bound to things would. Particualrly Stephen's ideas could be part of v1.1

Manu Sporny: Agree that we should try to get Steven's concerns into v1.1.

Wayne Chang: what are next steps? Stephen's concerns should be put in a new issue, the rest would be part of V2

Kyle Den Hartog: I can write a comment on the PR to state that

Ted Thibodeau Jr.: DavidC, if you could tidy up your last comment, it is really unreadable, makes it difficult to follow the thread

Ted Thibodeau Jr.: #788 (comment)

[TallTed]

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>.

[mwherman2000]

Issue #799 opened to track this as a Defer V2 issue.