W3C VC-LD Specification and Layered VC Specification: = interoperability at the application layer of layered spec

[SmithSamuelM]

I have copied my comments from issue #947 because they got lost in the general discussion.

VD-LD and VCC

This a concrete proposal that IMHO resolves the primary conflict in the community. It has two features:

• Lets a VC-LD be pure unadulterated JSON-LD. No compromises. Open world model.
• Lets everyone else who believes VCs are best implemented as a layered protocol use a layered protocol. Let's call VCC for VC Container specification.
• Interoperability between the VC-LD and VCC specification happen at the application layer of the VCC spec. The application layer contents are opaque to the VCC protocol. This interoperability is pure when the contents of a VCC are a JSON-LD VC.

Discussion

Those who think that VCs are best implemented with a layered model where only the topmost layer may or may not be an open-world model as determined by the application use case can then go build a layered model. And in those cases where the topmost layer benefits from an open-world model based on RDF then those users of VCC can still have high interoperability with VC-LD. For those applications of VCC that do not benefit from an open-world model then the primary advantage of VC-LDs is of little benefit to them and they can then benefit from avoiding the complexity and drag of an open-world model.

Drag

Much of the drag (cognitive dissonance) that we as a community experience (IMHO) is a result of the improper layering of the security concerns associated with the V in VC, and not due to the non-interoperability of an open-world set of claims. The triples in the claims can be conveyed in every case by a container layer to which the claims are opaque. The claims layer may of course, reference any meta-data in the container layer, but operationally this can be viewed as logging the container as an artifact but operationally, all the container layer needs to achieve its function is limited to the closed world set of container properties (not its payload). These container properties look like meta-data to the claims layer or may include identifiers that are subjects of claims. But because the claims layer is opaque to the container layer, there are zero dependencies by the container layer on any claim in the claims layer so contained. Triples in the claims layer may be dependent on properties in the container layer but not vice-versa. To reiterate, this allows the container layer to be a closed world model of limited scope whereas the claims layer may still include any and all triples it so desires.

Protocol Design Flaw

The drag IMHO is due to mistaking the fact that the claims layer can reference properties in the container layer as a license to collapse or flatten the container layer leaving only the claims layer. This is indeed an unfortunate protocol design flaw that is the root cause of our difficulties.

This layering now allows us to limit the interoperability discussion to only those properties necessary to achieve the functionality of the container layer. Any discussion of an open-world model is obviously out of scope and would only add drag.

Such a layered model then allows the user to decide if the payload benefits from open-world interoperability or not. But the payload (including all its claims or triples) has already been authenticated. The container layer makes a cryptographic commitment to the payload. This usually means some serialization of the payload. Any serialization will do from the perspective of the authentication layer. The authenticity is limited to this serialization. Any later expansion that may dynamically introduce semantics may weaken what can be verified against the commitment to the original serialization. But what we have achieved is total interoperability of the authentication layer because it necessarily is a closed-world model. The payload is universally simply a serialized artifact such as a hash or Merkle root or accumulator of the payload regardless of the serialization type (be it JSON, JSON-LD, CBOR, MGPK, CESR or whatever).

Layered Model

Authentication Layer and Authorization Sub-layer

I propose that for a "verifiable" credential, what is primarily being verified is authorship or authenticity, where authenticity is defined to be secure attribution to a DID as issuer. A secondary verification for some credentials is an authorization where authorization is defined to be evidence of entitlement (the dictionary definition of credential). We then have a container that provides an authentication layer whose function to to provide verifiable proof of authenticity (aka secure attribution to a DID as issuer) of its opaque contents, and we have an optional authorization sub-layer that, when employed, provides proof of entitlement to some DID (or another verifiable cryptographic construct) as the target of the entitlement.

The opaque payload could be a true pure unadulterated JSON-LD document (or not, depending on the application use case). All claims in that payload would be authenticated before they are ever opened. Any properties needed to provide proof of authorization (entitlement) would necessarily be provided in the authorization sub-layer, but forensic information about the entitlee could be part of the payload because forensic information is not required to verify the entitlement but for other conditional purposes such as recourse or enforcement.

This layered approach IMHO removes most of the friction this community is experiencing. The security of the "verifiability" employs a closed-world model limited to the authentication and authorization layers, and the open-world interoperability is unfettered by concerns about what happens in the security layer below. Proofs of authenticity look sane because they are clearly poofs of the container of opaque claims and not some ex post facto proof mechanism of an expanded payload.

Presentation Layer

This layered model can be further extended to include the proof of presentation which is different from authentication of the Issuer and authorization by the Issuer.

A presentation exchange protocol then can include the details of graduated or selective disclosure of the payload claims when appropriate. In many cases the payload of forensic information need only be conditionally disclosed especially when the entitlement properties are cleanly separated. Then proof of the presenter as target of the entitlement is the primary function of the presentation proof.

But once again, any property of the presentation layer can be referenced in an open-world claims layer as a artifact or log of the proof but those references in the claims layer are not operationally involved as a dependency of the presentation layer. Once again, we avoid the mistake of wrongly collapsing the presentation layer into the claims (payload) layer merely because a property of the presentation layer may be referenced in the claims layer. We have the discipline to recall that a reference down into a lower layer does not give us a license to collapse that lower layer (the presentation layer in this case).

[decentralgabe]

before getting too deep into this proposal I think it's important we get to the heart of what "interoperability" means.
this is certainly a viable path, but one that has tradeoffs...more specifically this means more code implementers need to write to make Verifiable Credentials work.

I think the best solution allows a minimal shared set of code to "work" for most, if not all, Verifiable Credentials.

By "work" I think a minimal set of functionality which I think of in term of validations:

• set of normative terms - is this document compliant with the specification?
• understanding of methods of extensibility (which one or more can be supported) - are there terms here not defined in the spec which I can understand through a spec-defined mechanism?
• signature verification - can I verify the integrity of the data that is being signed over?

The closer these layers can be to having a common base, the broader our out of the box interoperability can be, which I think is worth achieving.

So in my view the VC itself has three layers - signature, spec-defined data, spec-enabled data. I see LD, JSON Schema, and others in the last layer.

[SmithSamuelM]

@decentralgabe Not all layering is equivalent. The layering I am proposing is a function layering in the spirit of the ISO OSI protocol layering framework. Authentication, Authorization, and Presentation are formally defined functions in such a framework. These may or may take advantage of other constructs such as schema and function specific terminology. Because they are security focused functions, an open world model is antithetical to their function. Necessarily we want a very tightly defined set of roles and functions. In the ISO OSI framework layers are bounded by wrappers or envelopes. The contents of a higher layer is opaque to the function of a lower layer. This is a well established framework that has informed layered protocol design for 30 years.

[mwherman2000]

before getting too deep into this proposal I think it's important we get to the heart of what "interoperability" means.

In reference to "interoperability" or "VC interoperability" or "interoperability with existing implementations of JSON-LD", which case are we talking about?

Are the JSON-LD enthusiasts primarily focused on VC interoperability? ...or interoperability/compatibility with some existing JSON-LD software implementations? ...for example, if there are JSON-LD implementations that can't or won't automatically assume the presence of a default @context when the @context attribute is not specified in a VC.

I think it might be more a case of the latter (which in turn is responsible for creating the former issue in terms of "VC interoperability" but only as a side effect).

...clearly JSON-LD software implementations are "just software" and the problem could be fixed on the JSON-LD side, n'est pas? Fix the JSON-LD implementations

...or create a W3C Note ;-) to describe what sort of decorations need to be hung on a VC to be compatible with that (JSON-LD) unique software platform.

[TallTed]

@mwherman2000 — Please revisit your #982 (comment) and wrap each and every instance of @context in backticks ("`") like so, `@context`, such that this GitHub user does not receive updates about this thread in which they are not participating of their own accord.

[mwherman2000]

Those who think that VCs are best implemented with a layered model where only the topmost layer may or may not be an open-world model as determined by the application use case can then go build a layered model.

@SmithSamuelM I've developed a layered architecture reference model for DIDComm Agents based solutions to make it easier to explain the options that are available to developers creating decentralized identifier-based agent software systems. Perhaps the DIDComm-ARM can be extended further in the directions you described above.

In the meantime, here's a preview: https://hyperonomy.com/2022/11/29/didcomm-agent-architecture-reference-model-didcomm-arm-a-preview/

A detailed whitepaper will (hopefully) be available later this week.

[SmithSamuelM]

@mwherman2000 Certainly DIDComm ARM is more aligned with what a layered protocol means. The differences are that the layering I am proposing is not a channel based or session based protocol but works in a zero-trust authentic data at rest model. DIDcomm does a lot, too much IMHO. But the discussion should not be: should we have layers? but what layers should there be? and what are the properties of those layers? So I welcome a shift to the later as per your post.

[mwherman2000]

So I welcome a shift to the later as per your post.

@SmithSamuelM I agree we're (you and I) are talking about different dimensions/sets of concepts in terms of an overall (broad and deep) model for decentralized identifier-based software systems (would welcome a better label).

I believe you're asking or are focused on: what are the dimensions/sets of concepts that can be used to layer a VC ARM. ...almost like a third axis (or set of axis) that rise out of Layer 3 in the DIDComm-ARM. Correct?

Is so, for VCs, is it a 2 x 2 matrix of dimensions? ...2 x 3? ...something else?

[mwherman2000]

But the discussion should not be: should we have layers? but what layers should there be? and what are the properties of those layers? So I welcome a shift to the later as per your post.

@SmithSamuelM Here's a proposal for how to structure a layered verifiable credential model ...technically, it's more of a logical decomposition of a VC into its primary components. The components are:

1. Verifiable credential envelope
2. Inner credential
3. Proof

If composited together, these 3 components make up one (1) (complete) verifiable credential.

Each component can then have its own (largely independent) taxonomy of mandatory as well as optional features associated with it. We won't know how independent these component feature sets are until they're enumerated on a component-by-component basis. Check it out... (click the diagram to enlarge it)

The above VC reference model is highly consistent with Figure 5 in https://www.w3.org/TR/vc-data-model/#credentials. Unfortunately in the current VC DM, the JSON serialization doesn't delineate the "metadata" component as its own JSON object (in the same way "credentialSubject" and "proof" are their own objects delineated by their own set of outer braces). That is, the JSON serialization is not consistent with Figure 5.

UPDATE: To be more obvious in the application of my terminology:

• The "inner credential" component is the value of the "credentialSubject" property.
• The "proof" component is the value of the "proof" property.

[ChristopherA]

I agree with Sam what is emerging from these conversations that the problem with VCs (in particular the never ending fight between JWT vs JSON-LD) is that both choices force other devs into structures & architecture they don’t like.

A better architecture with layers may solve this. I know in particular my community’s requirements for privacy/progressive trust can’t be addressed by the current architecture, thus we offered an alternative with Gordian Envelope.

[mwherman2000]

Gordian Envelope

@ChristopherA can you add a link to your above post that describes (with examples) what a Gordian Envelope is. Thank you.

[David-Chadwick]

@ChristopherA

" my community’s requirements for privacy/progressive trust can’t be addressed by the current architecture,"

Could you say what these requirements are please. Clearly VCs depend upon a protocol, and I believe that a protocol can be created to selectively disclose PII and increase trust using the current DM.

[SmithSamuelM]

@David-Chadwick One of the important learnings with ACDCs is that selective disclosure is but one form of graduated disclosure. I am interested in @ChristopherA ideas on “progressive trust” seems might have some overlap with the concepts of graduated disclosure from ACDC of which contractually protected disclosure is one mechanism to build trust prior to further disclosure or which selective disclosure might be a mechanism for further dislcosure.

A layered protocol data model means we can talk about what goes in the layers. The current VC flat model really only contemplates two types of disclosure, full and selective. But graduated disclosure forces a more nuanced view of a disclosure protocol and therefore what goes in a disclosure protocol layer. This is what is historically called a presentation layer in the ISO OSI model. One of the nuances is that historically presentation was by a named or targeted identified entity by the issuer. Whereas a disclosure protocol is not so limited. A Discloser could be any entity, not merely the entity designated by the Issuer (e.g. and Issuee) if any. This nuance removes the holder binding ambiguity (see other issues on holder binding) A Discloser may or may not be an Issuee. The semantics of the act of disclosure may be different as a result, but how one arrives at agreement to the terms and conditions of disclosure is largely independent of those semantics thus making graduated contractually protected disclosure its own sub layer in a disclosure protocol layer.

[SmithSamuelM]

One of the severe limitations of the current VC model is that there is no mechanism for contractually protecting disclosure. Selective disclosure by itself implicitly permissions any use of the data so selectively disclosed. Its a free pass to any aggregator to de-anonymize the selectively disclosed data with any contextually linked information availabe to the verifier at the time of presentation. Whereas a graduated contractually protected disclosure can impose a liability on the verifier that prior to selective disclosure the verifier agrees not to de-anonymize the selective disclosed data nor to share it. I call this an anti-assimilation constraint. For example, in the classic proof-of-age selective disclosure example. I can use a cryptographic selective disclosure mechanism that makes it difficult for the verifier to link the age of the presenter to the presenter’s PII. I.e. no provable super correlator is provided by the presenter. But if the presenter chooses to pay their bar tab with a credit card, now the verifier has a super correlator the credit card number. As well as video footage from security camera’s theat they can use to deanonymize the person and defeat via contextual linkage the unlinkability of the selective disclosure. Obviously one could argue that one could pay with cash, But that limits the usefulness of the selective disclosure to a narrow subset of the user population. Whereas a graduated disclsoure with an anti-assimilation clause could be attached to both the age transaction and the CC payment transaction, limiting the contextual linkage of the two transactions to any purpose besides the transaction. The combination of selective and contractually protected disclosure is more comprehensive. It attaches strings to any disclosed data forbidding use not specifically permissioned.

[David-Chadwick]

Most of the above is beyond the VCDM because it depends upon the protocol used to transfer the credential. Furthermore, regardless of what protocol commitments are made an untrustworthy verifier can ignore them and still do aggregation or further disclosure (as we know from digital rights management). This is where the trust infrastructure comes in. So given that we need a trust infrastructure regardless of the VCDM and protocols, then we are now debating what functions can be left to the trust infrastructure's policies and procedures and which can be reliably dealt with using technology alone and which need a combination of the two. I believe SD requires both.

[David-Chadwick]

@mwherman2000 Where we appear to disagree is over the Verifiable Credential Envelope. Either that or you are missing another component from your model, namely the Credential Metadata. Note. This is meta information about the credential claims and is independent of the proof applied to the claims. So I am talking about such metadata properties as:

• the validity time of the credential/claims
• the id of the credential itself
• the schema controlling the contents of the credential/claims
• the evidence that was used when creating the credential/claims
• any terms of use regarding the use of the credential
  These are all valid metadata items that exist even before the credential has had a proof it, making it verifiable.

[mwherman2000]

@David-Chadwick First, I'm glad (almost ecstatic) that we have started to have a mutual understanding on some terminology. I had actually given up hope on these conversations. Thank you for persevering.

Where we appear to disagree is over the Verifiable Credential Envelope. Either that or you are missing another component from your model, namely the Credential Metadata.

I would also like to factor out the "credential metadata" from the Credential Envelope. In fact, in my own work on Structured Credentials, I do. I call the metadata stuff the Packing List (reference: https://www.youtube.com/watch?v=kM30pd3w8qE&list=PLU-rWqHm5p445PbGKoc9dnlsYcWZ8X9VX&index=1). So again, you and I are traveling the same path (in the same direction).

So if I agree with you, why is something equivalent to Credential Metadata missing from my decomposition? It's fairly straightforward: because in the current JSON serialization of a Verifiable Credential, the metadata properties are not their "own thing" ...they are not grouped into their own property ...an historical accident or whatever you want to call it.

In #982 (comment), I added the following update at the end of the post:

• The "inner credential" component is the value of the "credentialSubject" property.
• The "proof" component is the value of the "proof" property.

There is nothing in the current VCDM that enables me to make a similar statement about the credential metadata. There no way to say, hypothetically,

• The "credential metadata" component is the value of the "xyz" property. (e.g. the "metadata" property or the "packinglist" property.

This structuring is missing from the current VCDM. Are you and I still close? ...in terms of the direction of this discussion?

[mwherman2000]

@David-Chadwick p.s. Without changing the current VCDM, we can address one thing on your wishlist, we can easily add an optional "metadata" property to the "inner credential" ...here's an updated "VC decomposition" diagram...

It's still a problem (without an easy solution) to group the metadata properties in the VC Envelope. Any thoughts/ideas?

[David-Chadwick]

I do not see metadata as being in the inner credential, since it is data about this data. All data in the inner credential is described by its metadata, which necessarily must be outside of it (as is your envelope). So where you have placed it cannot be correct.

So let me ask you about your envelope. What is its purpose?

And how does it differ from my concept of the metadata about the inner credential?

[mwherman2000]

A big part of what I do is take new technologies and make them more understandable. The idea of a Verifiable Credential Envelope in which the Inner Credential is placed and the Envelope being subsequently closed and sealed (with a proof) is a set of abstractions that make VCs and the VCDM much easier to understand by software architects and developers, resulting in faster and higher adoption (hopefully).

@David-Chadwick have you had time to watch? https://www.youtube.com/watch?v=kM30pd3w8qE&list=PLU-rWqHm5p445PbGKoc9dnlsYcWZ8X9VX&index=1

Related, this weekend I finished a whitepaper where I had a similar set of goals for software architects and developers trying to understand and use DIDComm and DIDComm Agents. Here's a preview of the DIDComm Agent Architecture Reference Model (DIDComm-ARM): https://hyperonomy.com/2022/11/29/didcomm-agent-architecture-reference-model-didcomm-arm-a-preview/

[David-Chadwick]

You packing label is the credential metadata - you say so in your video. But your packing label is not mentioned in your diagram. So you are not including the metadata as a separate component in your diagram, which is the issue I brought up.

p.s. I should not have to watch videos for you to be able to explain to me your concepts. And I do not think the video is that helpful. So sorry, can we keep to text please. Otherwise the conversion will not be productive.

[David-Chadwick]

This is my much simpler representation

 --------------------
|                    |
| Proof              |
|                    |
| ------------------ |
||                  ||
|| Credential       ||
|| Metadata         ||
||                  ||
|| --------------   ||
|||              |  ||
||| Credential   |  ||
|||              |  ||
|| --------------   ||
| ------------------ |
 --------------------

[mwherman2000]

This is my much simpler representation

Is this intended to be a representation/model of the current VCDM @David-Chadwick? ...or are you proposing a new representation/model?

[OR13]

This is my much simpler representation

 --------------------
|                    |
| Signature          |
|                    |
| ------------------ |
||                  ||
|| JWT              ||
|| Header           ||
||                  ||
|| --------------   ||
||| JWT          |  ||
||| Claimset     |  ||
|||              |  ||
|| --------------   ||
| ------------------ |
 --------------------

[SmithSamuelM]

I think David's model is more generic and supports formats other than JWT. But the idea of both is correct IMHO. The proof in the outermost wrapper. Metadata about the container in the next inner wrapper which metadata is primarily to provide verifiability of the proof i.e. authentication. For example proof-of-issuance requires a mapping from proof to issuer. In the simplest form, the metadata is the issuer's identifier and the proof a signature using the controlling key-pair for that identifier. The payload is the innermost wrapper. The payload could be a claim-set in different serializations. Each wrapper is its own independent layer with its own data model. The payload could be an open world model without bleeding the complexity of such a model into the container or proof layers. Both models miss the nuance of an optional authorization sublayer as part of the metadata.

The main advantage is that the outer wrappers can be and should be closed world tightly specified data models that could more easily support implementations of multiple serializations and proof types in a secure way. The payload could be free to provide a claim set that is pristine also using different data models. This would support adaptation to different tool stacks and maximize reuse of existing tooling while allowing innovation and evolution. The claim-set can refer to the same identifiers in the meta-data layer but these are used as facts in the payload layer and are not functionally used to provide authentication or authorization for the container layer. Proof of issuance is much easier to manage if its principals are not co-mingled in the payload layer.

[David-Chadwick]

@SmithSamuelM

"Metadata about the container in the next inner wrapper which metadata is primarily to provide verifiability of the proof i.e. authentication."

This is not the intention of my credential metadata. Rather it is to provide information about the credential, such as its validity period, its schema etc. i.e. its data about the claims and is independent of the proof. The proof must have its own metadata such as its validity period, algorithm id etc. I have included this metadata within the proof envelope, but we could split proof into two wrappers namely: proof metadata encapsulating the credential metadata, and signature which encapsulates everything. I think that in @OR13 's diagram the JWT header equates to my proof metadata, in which case we will have 4 boxes and not 3.

[OR13]

Are we talking about removing or augmenting the VC and VP claims set members?

[David-Chadwick]

@OR13 My intention is that all the current properties are assigned to one of the containers, so that it becomes clear whether they are part of the VCDM or the separate (and independent) proof specifications.

[David-Chadwick]

@mwherman2000 See my answer above to @OR13 . It is so that we can better understand the current VCDM properties and assign them to the relevant container.

[SmithSamuelM]

To summarize, where we differ is that I define a layer as a function that includes the data or information needed to perform that function not as a specific wrapper. This is because each layer as a function requires a proof and those proofs are attached to or are proving other data needed by that layer. So the wrappers you use above don't represent the functional layers. IMHO functional layers better guide our design choices and allow for the intricacies of the associated crypto. This is not possible with merely data wrappers as layers. That is too simplistic a view and misses the most important design trade-offs.

[David-Chadwick]

I don't think our models are actually that different. Your container contains two parts, the metadata needed to validate the signature and the opaque payload. This equates to the signature and proof metadata of my 4 layer model.

 ----------------------
|                      |
|  Signature           |
|                      |
| -------------------- |
||                    ||
|| Proof metadata     ||
||                    ||
|| ------------------ ||
|||                  |||
||| Credential       |||
||| Metadata         |||
|||                  |||
||| -------------    |||
||||             |   |||
|||| Credential  |   |||
||||             |   |||
||| -------------    |||
|||                  |||
|| ------------------ ||
||                    ||
| -------------------- |
|                      |
  ---------------------

The fact that I have Credential Metadata and Credential inside the proof metadata is irrelevant to you as they are both the opaque payload of the proof layer from your perspective. I am simply modelling the two different types of property in the VCDM. But from your perspective both of these are the opaque payload.

We can then take the entire structure above as an opaque blob for the payload of another wrapping of proof metadata and signature (which is what we do in JWT-VC when we put the VC-JWT into a VP .

[David-Chadwick]

I do not agree with your characterisation of the authz layer because the Authorizer and Issuer are not always the same party. In RBAC and ABAC one party is the Issuer of the credential, and another party is the authorizer (i.e. the resource holder). When you travel abroad you use this model, as the US is the issuer of your passport and the UK border control is the authorizer of allowing you to enter our country.

[David-Chadwick]

I also think that once you introduce the authz sub layer into your container, this equates to the credential metadata of my model. If you are only interested in authentication, then the signature on its own (with the proof metadata) is sufficient for this. But if you now want to use this authenticated container for authz as well, then you need the credential metadata to tell the verifier something about authz being provided by the actual credential. For example, if the credential is your name, dob, and nationality (as in a passport), the credential metadata would contain the validity period of this data, along with a unique id number and type. The verifier, on seeing this type is "P" knows it is a passport type of authorisation.

[SmithSamuelM]

@David-Chadwick "and another party is the authorizer (i.e. the resource holder). " That is not how typically the term authorizer is used. The resource holder is the presenter is the authorizee. In a delegation then the delegatee can in turn become the delegator (authorizer) but that subsequent delegation requires another issuance. So we definitely have some terminology definitions to iron out. Now in federated identity systems or closed loop systems like access control systems (ABAC etc) or (object capabilities) (which none of which are not talking about here) you can have a more complicated authorization model where the identity provider issues a token that is a bearer authorization and the presenter/bearer of the token is sometimes viewed as the authorizer for a subsequent action (which is really a type of delegation). But the terminology becomes ambiguous when you mix in federated identitiy concepts or access control concepts. Lets not do that here.

Let me be clear, when I say that a VC is an entitlement which is a type of authorization that does not mean it is the same type of authorization that is implied in Access control systems or object capability systems. Think of entitlement as a license not an authorization token. If you are confusing the Issuee of a VC as the authorizer in a access control sense then we will not be able to have any kind of mutual understanding. They are not the same class of authorization, even remotely.

I can go into length at the architectural differences. The easiest way to understand those conceptual differences is to view access control as a closed loop authorization system where the issuer is also the verifier and the token (resource) embues the holder with the authority to "authorize" an action that is verified by the issuer. Typically the token is a bearer token (i.e. has no designated issuee). Whoever holds the token has the authority. But this is why access control tokens are so short lived because they are fundamentially insecure, any bearer will do. So they have to expire rapidly to prevent replay attacks.

Whereas the Issuer/Holder/Verifier model of VCs treats authorizations as an open loop system where the verifier is never the issuer and the Issuee must be explicitly designated in the authorization otherwise the verifier can't verify that the Issuee has the authority given to it via an authorization locked to that Issuee. This allows the VC to be long lived and have dynamic revocation as well as privacy (as opposed to closed loop which requires verification to phone home to the Issuer to validate the authorization). A verifiable data registry is required in an open loop system with long lived but dynamically revocable credentials to maintain the privacy separation between Issuer and Verifier.

But I get why the VC data model gets confused because very few have thought about it as a new type of authorization and confuse it with other types of authorization such as access control.

The goal should be interoperable security first. This means having precisely defined security models and not confusing authorizations as long lived entitlements in a open loop model with short lived access control tokens in a closed loop model.

If it would help I would be fine with using the term “entitlement layer” instead of authorization layer.

Hope that helps.

[mwherman2000]

The fact that I have Credential Metadata and Credential inside the proof metadata is irrelevant to you as they are both the opaque payload of the proof layer from your perspective.

@David-Chadwick Using the current VCDM as a guide,
a) what do you consider to be the Credential?
b) where is the dividing lines/boundaries of the Credential?
c) do you, for example, consider the value of credentialSubject to be the (boundaries of the) Credential? ...or something more/less?

[SmithSamuelM]

We had a similar issue come up in the DID specification and the DID resolver specification. The DID resolver and DID specs are not independent of each other. There are clear dependencies between the two. This meant revising both to reflect those dependences. Likewise a proper layer design can’t treat the proof specification as completely and totally independent because a functionally secure proof of Issuance/Authentication is dependent on metadata in the containers that must be committed to by the proof. So we should revise the proof specification similarly to reflect those necessary dependencies. This is another layer violation (treating the proof as independent of the data model for the containers)

[David-Chadwick]

@mwherman2000 c) is the credential (ie. the credential subject object and its properties, sometimes called claims). All the other properties are metadata about the credential subject's properties.

[mwherman2000]

@David-Chadwick Thank you for the clarification. Precision is important.

All the other properties are metadata about the credential subject's properties.

Now regarding the "the other properties are metadata about the credential subject's properties", I believe "the other properties" need to be divided or separated into 2 types (maybe more):

1. Part 2 of "the other properties" is metadata about the Credential (defined to be the value of credentialSubject - the definition of Credential we agreed to above)
2. and then there's Part 1 of "the other properties" is metadata about the larger structure: the verifiable credential structure exclusive of the value of the credentialSubject.

There may even be Parts 3, 4, 5, ... for describing other aspects of either the Credential or the Verified Credential (exclusive of the Credential) ...I think this is maybe where @SmithSamuelM is coming from?

[David-Chadwick]

@mwherman2000 I am not sure what your Part1 and Part2 refer to, but anything to do with proofing the credential (i.e. to do with the verifiable credential) is not metadata about the credential. It is metadata about the proof. This is what my diagram is trying to show. So I agree that there are two sorts of metadata, but they need to be kept separate and not interwoven. When you remove the proof from the verifiable credential (to leave the credential and it's metadata) you remove both the signature and the proof metadata. You can then add a completely different proof to the credential (and its metadata). In this way you can convert a JWT-VC into a LD-Proofed VC, (and back again) whilst the underlying credential (and its metadata) would not change.

[David-Chadwick]

@SmithSamuelM

"Likewise a proper layer design can’t treat the proof specification as completely and totally independent because a functionally secure proof of Issuance/Authentication is dependent on metadata in the containers that must be committed to by the proof."

Perhaps this is where we disagree. At the technical level I believe that signing/authenticating information can treat that information as a blob and the signature function should be independent of the blob. i.e. the signing function should be able to sign any blob. However at the semantic/administrative level clearly the signer will need to know what they are signing in order to authenticate it. (E.g. if the blob says "I authorise you to empty my bank account" I would not be willing to sign it. However the technical infrastructure is perfectly able to sign it).

I could argue that trying to intertwine the semantic/administrative level with technical/syntactic level over complicates the system and that keeping them separate simplifies the overall system. And as you said "Its a truism of security systems design that simpler is stronger".

[SmithSamuelM]

@David-Chadwick As Einstein is reputed to have said “ Everything should be made as simple as possible, but not simpler.”. For an authorization/entitlement/credential. the target of the entitlement, i.e. the entitlee, credentialee, authorizee MUST be part the the data being proven by the Issuer otherwise there is no way for the target to proof at the time of presentation that they indeed are the intended (by the Issuer) recipient of the entitlement/authorization/credential. So while simple is stronger is a truism, in this case leaving out the identifier of the target is “too simple” because without it the proof of Issuance no longer secures the intended target. All that is needed is the cryptonym of the target, nothing else. This is “minimally sufficient means” which is the design aesthetic that captures both simple is better but not too simple. So multiple proof types from the designated issuer ( recall that the Issuer ID is also in the data being proven) are still enabled. And a group identifier for the issuer allows multiple group members to provide independent proofs. The key is to understand the function and not try to do some overly simplistic separation of semantic vs syntatic. The semantics of authorization are essential to an authorization sublayer. But only the semantics of authorization. The problem is not separation of semantics from syntax. Its what semantics and what syntax are appropriate for each layer. And not mixing either syntax or semantics from other layers.

Note thqt the issuee identifier is using PKI. The Issuee identifier is public is its derived from public keys from a public/priate key pairs and is therefore controlled by the private keys. Therefore only the Issuee (ie.e the entity that controls the private keys) can proof that they indeed are the Issuee. This is essential to the Issuer/Issuee/Verifier model of open loop authorization. We are NOT talking about bearer authorization tokens endemic to closed loop authorization systems where the verifier MUSt either be the Issuer or affiliated (same trust domaine) with the Issuer or federated with the Issuer. A bearer token means that any verifier of the authz token can now impersonate the presenter of that token. These tokens are inherently replayable and therefore depend on other mechanims to mitigate such attacks. An open loop model on the other hand depends on the inherent properties of PKI, only the entity who controls the private keys can make a verifiable presentation where they successfully purport to be the target of the authorization (i.e. the entitlee, credentialee, authorizee).

Without this we do not have verifiable credentials.

Despite the best efforts of some community members, the essential self-certifying (decntralized) PKI underpinnings of a verifiable statement where there is an Issuer, on optional Issuee, and a Verifier, by whatever name we call them (Verifiable Repute, Verifiable Container, Verifiable Claim, Verifiable Credential) have not changed since the original Open Reputation white paper that I wrote in 2015 that defined the construct.

https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/open-reputation-low-level-whitepaper.pdf

[David-Chadwick]

But we already have what you require in the current VP-JWT spec that is independent of the embedded VC. This contains the VP issuer (holder/entitlee) and audience (issuer in your unfederated model - which (as an aside) I think is too restrictive). This is the proof metadata of my 4 layer model. So the RP can verify that the VP is intended for it, verify the signature, then go onto inspect the VC that is embedded in the VP to find out which privileges the VP holder is requesting.

[SmithSamuelM]

Likewise the ACDC specification provides a similar construct but takes advantage of other features not in VP-JWT. So a big tent approach for layered VCs would try to find the minimally sufficient means for each layer that maximizes interoperable security between the various stacks (JOSE, COSE, ACDC/KERI, JSON-LD, Anoncreds, etc). This can be done by having essentially independent constructions for each layer:

Authentication (and proofs thereof)
Authorization (and proofs thereof)
Presentation (and proofs and protocols thereof) *
Payload

• Presentation is more complicated because of graduated (partical, compact, selective) disclosure mechanisms. Which in some cases reflects dependencies back into authentication and authorization. But the self-certifying identifier underpinnings of the crypto minimize those reflections and make the whole stack very manageable (unlike federated identity).

If we do it well, we can support mashups of the tooling stacks across the layers. We have serializations and proof algorithms. If we want broad adoption there are good reasons not to use one serialization or one proof algorithm.

Hence the thesis of this proposal. Either we as a W3C community can just call this the W3C VC-LD spec and those have good reasons not to use only JSON-LD (like me) can build a layered VCC specification somewhere else. Or this W3C community can recognize that a layered VCC spec enables a big tent approach and take that path instead.

[David-Chadwick]

The serialisation and semantics of the innermost credential must be standardised otherwise once all the outer crypto layers have been stripped off you will end up with a sequence of bits that you cannot understand. The mission of the VC WG must surely be to standardise the credential and its metadata, and then to allow this payload to be protected by any signature and proof metadata, preferably by already existing standardised cryptographic ones so that we do not have to re-invent the wheel.

[SmithSamuelM]

@David-Chadwick "The serialisation and semantics of the innermost credential must be standardised ". I would say the semantics of each layer must be standardized which is done properly can support more than one serialization. Then you do not end up with a sequence of bits you cannot understand.

ACDCs with CESR do this elegantly IMHO as a CESR stream can have interleaved versioned JSON-CBOR-MGPK-CESR seralizations. A stream parser can easily disambiguate and cold start. There is no technical reason we can't support multiple serializations. The problem is simpler than supporting multiple proof types as there are way more practical proof types that require way more resources (libraries) to support than practical serializations. And the innovation in proof types will explode once post-quantum crypto becomes standarized.

Indeed the technical challenge will be managing the proliferation of crypto signature types and proof types. If we have not learned anything from DID method proliferation it is that proof types will proliferate and frankly its a pipe dream to believe that there will be broad interoperability based on merely a standard serialization or even standard ways to convert the semantics of payloads between serializations.

So if you really want rigid interop then just build VC-LD and only allow LD-Proofs and rigid JSON-LD serializations. Then you will have an interoperable island of JSON-LD RDF tooling. But not interoperable security.

But if you want interoperable security, then serialization is a non-issue because its easy to identify the serialization. Interoperability is only useful when you provide the ability for any verifier to appraise the key state and the proof type and decide if its secure enough to accept. If not then you won't have acceptance, not because a verifier can't recognize or can't process the proof given the key state but because the proof is too weak to meet that verifier's standard of security so they will not accept it. The "interoperability" in interoperable security means a common understanding of the security posture of the other party in any interaction, including parties to interactions that are upstream and downstream of the given interaction (hence chaining).

If we don't build a standard that gives the verifier (in a totally decentralized way) the ability to appraise the key state and proof in order to decide if it meets their (the verifier's) security (authenticity, confidentiality, privacy) requirements, then we are building a house of cards. We would repeat the worst outcome of federated identity which forces verifiers (relying) parties to trust the issuer/presenter/federator regardless of the verifier's security policy.

And not just the common use of verifier, all parties are in some sense verifiers. The Issuee needs to be able to appraise the key state and proof of the Issuer. Every participant needs to be on the same level playing field. We call this end-verifiability. Forcing any participant to use a compromised (from the participants perspective) tool stack is just repeating the mistakes of the past.

This will no doubt result in non-interoperability of payload data flow. Not because any party to an interaction can't understand what the other party is saying, but because the security by which the other party is saying it is inadequate to accept the payload data. This is why the payload MUST be opaque, so that the security layers can operate independent of the payload serialization. A hash is sufficient to represent the payload from a security layer perspective as long as the hash type is known.

This is the essence of what I mean by saying we must have interoperable security first. The ability to understand the security of the other party in order to appraise it and then accept or deny makes the security interoperable. Not forced acceptance of what the other party is communicating simply because they use the same syntax and serialization no matter how weak or strong the security.

[mwherman2000]

I've been working on the following taxonomy/roadmap metamodel for a DIDComm-based ecosystem (Web 7.0). I'm offering it up as an example of something similar that can be created for the VCDM.

UPDATE 2: At 1:16:12 into the tutorial https://www.youtube.com/watch?v=ZFb4OXov7wg&list=PLU-rWqHm5p44AsU5GLsc1bHC7P8zolAAf&index=3&t=4572s, I describe how to use a roadmap metamodel like the one depicted below for Web 7.0. The idea is to create a similar roadmap metamodel or compass for Verifiable Credentials (with different dimensions/axis). @SmithSamuelM what do you think? ...part of the message is to (collaboratively) manage VCs more like a product.

[TallTed]

@mwherman2000 —

I'm nearly completely baffled by your graphic. There's almost zero flow from one concept to another; instead everything seems to be delivered (or fed?) by DIDComm-ARM. Somehow this new "Web 7.0" springs to life in its entirety, with no obvious connection to any of its predecessors, including but not limited to the mostly undefined "Web 5.0" which itself is just a mongrelization of "Web 2.0 + Web 3.0", where "Web 3.0" is even less defined than "Web 2.0".... And what changes between "Web 7.0" and "Web 7.1"?

Even if all this were clear, there's the question of how this image fits into the conversation in this thread, to which, as far as I can tell, the answer is, "it doesn't."

[mwherman2000]

@TallTed I'm sorry you weren't able to grasp the idea of taxonomy/roadmap metamodel ...and this being one example. I don't have more to add unless you have a more specific question.

[mwherman2000]

@TallTed If one of your questions is: What is Web 7.0?
Checkout https://hyperonomy.com/2022/12/18/web-7-0-didcomm-agent-architecture-reference-model-didcomm-arm-0-40-december-18-2022/.
It's a topic of discussion in the DIF DIDComm WG UG - and not, as yet, in W3C/CCG.

[TallTed]

@mwherman2000 —

I'm sorry you weren't able to grasp the idea of taxonomy/roadmap metamodel

Nice slap in the face, there. More than a little bit condescending. I refer you yet again to the Positive Work Environment at W3C: Code of Ethics and Professional Conduct which covers all interactions within all W3C groups (including but not limited to the CCG and the VCWG).

I have worked with many taxonomies, roadmaps, metamodels, and blends thereof. Your diagram does not conform to my understanding of any of these, including such blends.

Checkout [a page which leads to a PDF of 80+ pages of dense text and images]

If it takes 80+ pages of supporting text to make your diagram comprehensible, something's gone wrong somewhere. Part of what I find there is that your "Web 7.0" ignores and skips past what others are discussing as "Web 5.0" (which is, according to some, the sum of "Web 2.0" and "Web 3.0", neither of which has been rigorously defined anywhere, so far as I'm aware, though the meaning of the former is reasonably consistently understood; according to others, it's meant to label the "Emotive Web"), as well as the inexplicably yet-to-be-discussed "Web 4.0" or "Web 6.0".

[Web 7.0 is] a topic of discussion in the DIF DIDComm WG UG - and not, as yet, in W3C/CCG.

The W3C-VCWG operates this GitHub repo, with a fair bit of interaction with the W3C-CCG. Topics discussed by the "DIF DIDComm WG UG" (I was able to locate the DID Communication Working Group but no UG therein?) should not be assumed to be familiar, understood, monitored, etc., to/by W3C-connected participants here. Links to such discussions are always appropriate and helpful if not always necessary.

[mwherman2000]

I want to re-energize this discussion in favor of @SmithSamuelM 's proposal for a multi-layered architecture reference model for Verifiable Credentials. The primary reason is: competition.

As I've been talking to larger and larger audiences about Web 7.0 and the DIDComm Architecture Reference Model (DIDComm-ARM), a number of people have questioned Web 7.0's focus on VCs ...and there is no reason for focussing only on VCs. A DIDComm Message Attachment can embed, by value or by reference, any type of information - in any data format.

Here's a small sample (which includes mDLs, X.509 certificates, audio recordings, temperature sensor readings, Office documents, concert tickets, etc. etc.): https://hyperonomy.com/2023/01/17/didcomm-message-attachment-types/

In the real world, VCs face real competition and I believe one effective way to combat this competition is a multi-layered Verifiable Credential architecture reference model (similar to the Web 7.0 DIDComm-ARM diagrams I've shared above). I don't have enough spare time to help out with the VC-ARM right now. I hope someone picks it up and moves the goalposts for VCs.

[brentzundel]

@TallTed I'm sorry you weren't able to grasp the idea of taxonomy/roadmap metamodel ...and this being one example. I don't have more to add unless you have a more specific question.

@mwherman2000 comments such as this are absolutely uncalled for.

[mwherman2000]

I don't have enough spare time to help out with the VC-ARM right now. I hope someone picks it up and moves the goalposts for VCs.

I actually ended up backing into some work on a layered "credential" model for the Web 7.0 Trust Spanning Layer Framework. Check out slides 13-31 here: https://www.youtube.com/watch?v=rrFfuUHHmr4&list=PLU-rWqHm5p44AsU5GLsc1bHC7P8zolAAf&index=5&t=607s . It's a lot of slides but it's best/a requirement to watch them all.

This could serve as a starting point for adding an optional layer to support JSON-LD (and RDF) ...and their eventual removal from the core VCDM specification.

Cc: @SmithSamuelM

[mwherman2000]

Here’s a pre-proposal for what I’m calling the VC Architecture Reference Model (VC-ARM) aka VC Blood Types. Any feedback? Your thoughts? Are there additional dimensions?

• The VC-ARM is a proposed overlay on top of the existing Verifiable Credential Data Model (VCDM) specifications.
• The VC-ARM is not intended to be a net new VCDM specification; just an overlay.
  • Maybe an overlay specification if such an animal exists. ..perhaps something called a poly-specification?
• Where should the VC-ARM poly-specification be incubated, birthed, and nutured?
  • W3C?
  • DIF?
  • ToIP?
  • Other? ...a new foundation for poly-specifications?

I’ll produce a video tutorial sometime over the weekend.

[mwherman2000]

UPDATE: I've renamed the tutorial to:

• Internet Credential (InterCredential) Architecture Reference Model 0.63 (https://www.youtube.com/watch?v=kw3dhx7EYiE&list=PLU-rWqHm5p44AsU5GLsc1bHC7P8zolAAf&index=5)

Where should the VC-ARM poly-specification be incubated, birthed, and nurtured?

• W3C?
• DIF?
• ToIP?
• Other? ...a new foundation for poly-specifications a la the G.U.T?

What dimensions need to be added and how can they be depicted? For example, ...

• Cryptographic Suites
• Authentication
• Authorization
• …

Cc: @SmithSamuelM @dhh1128

p.s. It's also time to re-read the whole thread. :-)

[Sakurann]

RESOLVED: The base media type for the VCDM is credential+ld+json. @context is required (MUST) in the base media type; other media types MAY choose to include @context. Serializations in other media types (defined by the VCWG) MUST be able to be transformed into the base media type. Another media type MUST identify if this transformation is one-directional or bi-directional. Bi-directional transformation MUST preserve @context. Transformation rules MUST be defined, but not necessarily by this WG.

[TallTed]

@Sakurann — Please revisit #982 (comment) and wrap each instance of @context in code fences, a la `@context`.