vc-data-model

vc-data-model copied to clipboard

Currently we have:

assertionMethod -> issuing credentials authentication -> signing verifiable presentations

I suggest we add support for capabilityInvocation and capabilityDelegation, and we harmonize the ZCAP-LD / object capabilities APIs with the VC Data Model.

As an issuer I should be able to issue a ["VerifiableCredential", "AuthorizationCapability"], using capabilityDelegation proof purpose.

As a subject and holder of an AuthorizationCapability, I should be able to use capabilityInvocation proof purpose, when construction a ["VerifiablePresentation", "CapabilityInvocation"].

When verifying a ["VerifiableCredential", "AuthorizationCapability"], the verifier MUST use capabilityDelegation verification relationship.

When verifying a ["VerifiablePresentation", "CapabilityInvocation"], the verifier MUST use capabilityInvocation verification relationship.

These changes would allow tooling for verifiable credentials to be useful for capabilities and vice versa. In absence of these proposed changes, a lot of code duplication would be required, for ultimately what amounts to s small data model changes... different types and proofPurposes.

These changes would also assist in expanding the VC Data Model to handle authorization more generally.

Here is a complete example of what I mean:

• hypothetical spec
• working examples

This is hard to fully understand the implications of without an actual ZCAP-LD spec to compare against.

The use of caveats in the examples catches my eye because I've been wondering lately what the actual differences between allowedAction and caveat are supposed to be? Your examples don't look right to me.

Beyond that, ZCAPs are not Verifiable Credentials. Pulling in @cwebber @dlongley @David-Chadwick .

For what it's worth - I agree with differentiating zcaps from vcs, and also fully agree the former does not strictly need the later. Your name, driving license, or any other claim about your identity or attributes, has no bearing on the evaluation of a capability invocation.

On the technical level, ZCAP-LD apparently just requires plain JSON-LD and the security vocabulary. There is no dependence whatsoever on VerifiableCredential nor VerifiablePresentation.

The converse is also true. VCs have no dependency on ZCAPs and do not need ZCAPs in order to be used for authorisation purposes. VCs (and their physical equivalents) are already used for authorisation purposes every day. I see no reason to have ZCAPs. VCs can do everything ZCAPs can do and more. (But we have already had this discussion over a year ago)

I don't think we should be mixing identity claims and authorizations. I think the separation we have now is good and useful, and helps us avoid potentially dangerous (for both security and privacy) combinations.

Identities are authorisations today. You use your age to buy alcohol. You use your driving license to hire a car. You don't need a ZCAPs for any of these. ZCAPs are a distraction. VCs are perfectly adequate. The entire RBAC/ABAC model is based on identities.

I didn't post that hypothetical ZCAPs as VCs example to start a flame war, but to highlight weaknesses in the existing specs that are in my opinion, unnecessary and confusing for developers.

In the VC Data Model:

• there are only 2 proof purposes and they are explicitly NOT for capabilities
• the VC Data Model has a format "VC-JWT" which begs the question of access_token VCs...

In the ZCAP-LD spec

• the spec needs better examples
• the spec described a relation to VCs, but would require separate code too implement (a subset of what is required to support JSON-LD VCs)
• the spec has no support for JWTs

From a crypto perspective both ZCAPs, access_token and VCs are all semantic sweeteners on top of digital signatures... the fact that they are not all the same kind of sweetener is confusing and requires chef's to keep Splenda, brown sugar, powdered sugar, Sweet 'N Low .... in their pantry and use combinations of them to accomplish both authorization and authentication.... in my opinion, needlessly....

If I want to handle everything with JOSE, I can use id_token and access_token.

If I want to handle everything with JSON-LD I can use VC and ZCAP.

An obvious question is: why can't I use VC as either JWT or JSON-LD for both authorization and authentication?

The answer is that today, we think it's a good idea for that to be impossible.... I think this harms the adoption of VCs and in particular the JSON-LD variants, because unlike JWTs and JOSE, JSON-LD VCs / ZCAPs do not have years of authorization examples for developers to draw on... they have the VC Data Model and ZCAP-LD spec...

With small changes to how ZCAPs are formed they easily COULD be VCs.... and developers could bake authorization and authentication cookies using a single spec.

The VC data model is open. Any property can be assigned to a subject ID by the issuer. So an issuer can assign a capability attribute to a subject ID in just the same way that it assigns an identity attribute to it. The subjectID is also optional, so the capability attribute can be a bearer token when the subject ID is missing. So I fail to see why VCs cannot be either identity tokens or authorisation tokens or both using the existing standard model.

@OR13 said With small changes to how ZCAPs are formed they easily COULD be VCs... I agree with you. I see no reason to duplicate the encoding formats and rules to create 2 standards when one standard can fulfil both requirements. Which misguided person said "if one standard is good then many standards must be better"?

From an adoption on secure tooling perspective. It makes sense to have one verifiable container standard with multiple semantics on how to interpret the contents of that verifiable container. Verifiable means verifying signatures not anything else. Thus to have two different verifiable container standards each with different security tooling and signature verification processes merely to convey two different attribute semantics means two security stacks which separably opens up vulnerabilities. The hard part, the part we must not get wrong is the signature verification which means establishment of control authority over the identifiers to which the signatures are ascertained. We want one and only one way to do that. And lacking that we want one and only one tooling stack to do that. Given how hard it is to solve the signature verification/identifier problem, wanting yet another signature verification standard merely to convey an authorization attribute semantic versus a non-authorization attribute semantic is needless complication. Thinking of VCs as Verifiable Containers not Verifiable Credentials remove semantic dissonance. (The english definition of credential is a type of authorization). The verifiable in VC refers merely to signature verification not anything else. I know everyone on this thread knows that already, but subconsciously it helps me anyway to reinforce that the VC standard is merely a standard for verifying signatures on some container of data. The semantics of the data are free wrt the standard verification process. As @David-Chadwick points out, anyone can define their own schema for the semantics of what goes inside the container.

My suggestion is that we want a single stack of thin layers not multiple stacks of parallel thick layers. Only the top layer splits into multiple "semantic" applications as shown by the vertical bar below. (note first is bottom last is top)

Establish Control Authority over PKI for Signatures Authentic Data Containers with Verifiable Signatures Chaining Containers (semantics for chaining containers conveyed inside containers) Attributes | Authentications (semantics conveyed inside containers)

The chairs feel that work on this issue is outside the scope of the maintenance working group. This doesn't mean work cannot continue, but that it would need to be included a future version of the specification.

thanks @brentzundel I agree.... I propose we handle this as follows:

1. create a ccg work item that works to unify verifiable credentials and https://github.com/w3c-ccg/zcap-ld

2. setup a w3id.org namespace for capabilities under credentials: https://github.com/perma-id/w3id.org/tree/master/credentials which defines the same terms that are used by did core for these features

3. Work to explain how capabilities and vc's work with and without dids by providing better examples and helping to update zcap-ld.

The issue was discussed in a meeting on 2022-08-10

• no resolutions were taken

View the transcript

4.3. Define v2 context (issue vc-data-model#756)

See github issue vc-data-model#756.

Kristina Yasuda: In the last comment it looks like there is agreement to talk about it in CCG.

Orie Steele: I remember the context for this. In the 2 data model objects Credentials and Presentations, there is something people have been doing, which is related to the previous issues. Proof of possession. The current data model doesn't support this..
… I wantet to discuss the relevance of capabilities related to delegation.
… I would love for VCs to be a solution for capability systems, but we need to agree on this issue..
… If we think of capability systems as subset of VCs, then we get a "for free" representation of capabilities..

Manu Sporny: +1 - we should discuss this, -1 for VCs being used as capabilities..

Orie Steele: Mostly related to what do we mean by "authentication".

Kristina Yasuda: Will keep the issue open..

proofPurpose is now handled by the Data Integrity spec, which includes the proof purposes requested in the initial issue AND does not limit the addition of new proof purposes.

Marking this issue as pending close in 7 days unless there are objections.

https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L109

I'm going to close this, since I opened it.