Various discussion points for VC-JWT Specification

[nadalin]

Up level the VC-JWT to be a first level data model independent from VC-Data Model specification. The current data model is not the best data model for JSON Web Tokens from many perspectives. JSON does not need C14N and JSON-LD does, there are no proven (mathematical) algorithms for C14n and JSON-LD at this point in time, We already have JWS for JWT and no need for other signature types.

Remove the JSON-LD requirement of having @Context as it really does not work for proper namespace declaration and interoperability

Remove the JWT claim transformation requirements (put base JWT claims in the VC Data model). There are integrity issues doing this and there is no reason to do this if we keep with the JWT signature algorithms, so should not have to transform headers or claims from JWT

The usage of JWE should not be out of scope, as this may provide selective disclosure.

There does not always have to be a relationship between the verifier and issuer, if the verifier has to trust the issuer then there is a relationship, this can and will lead to collusion. The verifier only has to verify the signature of the verifier not trust.

There are concerns about the proof_property and if this is a MUST or a MAY, as the spec seems to contradict itself Could be editorial bugs. We tried to differentiate between credentials (no proof) and verifiable credentials (with proof). There are probably editorial errors which you could point out and get fixed

[TallTed]

@nadalin -- Please edit your initial comment here, and wrap the @context string (in your second paragraph) in a code fence (easiest is single backticks, as `@context`), as that GitHub user has never participated in any relevant discussions or groups.

[OR13]

Remove the JSON-LD requirement of having @context as it really does not work for proper namespace declaration and interoperability

-1 to this.

You can already sign JSON with JWT, JWS... see the numerous libraries that support this.

This proposal destroys interoperability that people, organization and governments must be able to leverage that are enabled by advanced features of verifiable credentials including open world extensibility.

If you think json only provides enough context, I direct you to the word:

https://vocabulary.transmute.industries/ns/attestation/

We have known about these challenges for a long time, there is extensive literature on this subject.

It is a fact that semantic ambiguity is a challenge some of us face, sometimes in every standards meeting we attend.

And most importantly, you can already use vanilla JWS and JWT to accomplish what you want today, so there is no need to destroy the hard work and value created by the extension to these technologies we have come here to build.

Remove the JWT claim transformation requirements (put base JWT claims in the VC Data model). There are integrity issues doing this and there is no reason to do this if we keep with the JWT signature algorithms, so should not have to transform headers or claims from JWT

Not sure about this.... It seems MUCH simpler to just allow for JWS, where no mapping is required.

Let's think through the rest of this though, let's assume we remove vc or vp from the claims set.

We now have iss and issuer. In order to preserve semantic processing after verification (see first comment). We need to include @context in the claims set, and it needs to provide term mapping for iss to issuer (the IRI part, not the term part). And same for all the other "in addition to" claims.

This then allows for VC-JWT to be processed identically to any other well formed graph fragment.

I could get behind such a simplification to the mapping rules, if the complexity moved from the mapping to the context, so that semantics were preserved 1-1.

If thats not possible to do, they this is actually just breaking everything for no reason.

I think it's probably MUCH, MUCH safer to just make the claims set for a JWS, the credential itself... and stop trying to map to JWT.

After thinking it through, -1 to this idea of altering the JWT mapping.

The usage of JWE should not be out of scope, as this may provide selective disclosure.

+1 to this, JWE should be a legal way to secure Verifiable Presentations

There does not always have to be a relationship between the verifier and issuer, if the verifier has to trust the issuer then there is a relationship, this can and will lead to collusion. The verifier only has to verify the signature of the verifier not trust.

I don't understand what point is being made here... at a minimum the verifier trusts the issuer to:

1. protect private keys
2. serialize to JSON correctly (not create prototype pollution or regex vulnerabilities)
3. not lie about subjects
4. not produce data that is so poorly defined so as to fail to meet the verifiers requirements in an obvious way

There are concerns about the proof_property and if this is a MUST or a MAY, as the spec seems to contradict itself Could be editorial bugs. We tried to differentiate between credentials (no proof) and verifiable credentials (with proof). There are probably editorial errors which you could point out and get fixed

Agree, especially with this part:

We tried to differentiate between credentials (no proof) and verifiable credentials (with proof).

Sadly it does not consistently apply to VerifiablePresentations.

In the core data model, a Verifiable Presentation may have a proof (internal or external).

As a holder, I should be able to use a JWE to secure a Verifiable Presentation without a proof. As a holder, I should be able to use a JWS to secure a Verifiable Presentation and then use a JWE to protect it. As a holder, I should be able to use a JWT to secure a Verifiable Presentation.

A mapping should be defined in this repository for all JWT production rules.

We should either create a new repo to support JWS / JWE, or we should expand VC-JWT to be VC-JOSE and provide better mappings in one single repo. I am in favor of the latter.

[mprorock]

Remove the JSON-LD requirement of having @context as it really does not work for proper namespace declaration and interoperability

-1 to this.

big -1 to this as well - I concur with Orie on this and feel that removal of @context is extremely harmful to the work in general and will lead to fragmentation, much less remove much of the meaning and power that VCs have. I am however, a fan of, and understand the need for private claims - adding a sane @vocab entry to the main context would facilitate this quite nicely

+1 to this:

We now have iss and issuer. In order to preserve semantic processing after verification (see first comment). We need to include @context in the claims set, and it needs to provide term mapping for iss to issuer (the IRI part, not the term part). And same for all the other "in addition to" claims.

This then allows for VC-JWT to be processed identically to any other well formed graph fragment.

I could get behind such a simplification to the mapping rules, if the complexity moved from the mapping to the context, so that semantics were preserved 1-1.

[OR13]

This issue seems to be stale

[OR13]

Marked pending close over 1 week ago, closing.