4.3 Types

[nadalin]

"The type system for the Verifiable Credentials Data Model is the same as for [JSON-LD] and is detailed in Section 5.4: Specifying the Type and Section 8: JSON-LD Grammar"

Should not be forced into JSON-LD as the type data model, this should allow for JSON models such as JWT/CWT. There are many parsers and verifiers out there today for JWT/JWS

[brentzundel]

It was explained to me that selecting the type system for the Verifiable Credentials Data Model to be the same as the type system for JSON-LD, freed the Verifiable Credentials Data Model from needing to specify its own type system. It is my understanding that using the JSON-LD type system for this data model does not force any implementor to use JSON-LD, but that JWT/JWS are fully compatible with the type system specified. @msporny or @dlongley may have more detail to share in addressing this issue.

[msporny]

Should not be forced into JSON-LD as the type data model, this should allow for JSON models such as JWT/CWT. There are many parsers and verifiers out there today for JWT/JWS

Can you please be concrete in the problem that you think this creates? What specific technical issue are you concerned about and what specific and concrete technical solution are you proposing?

[nadalin]

@msporny I'm very concerned about the use of JSON-LD and how proof mechanisms would work, I know how they will work with JWT as this is proven work, the lack of a completed signature and C14N specification is a show stopper. So I'm proposing a step back and being able to represent a VC as a JWT and use the JWS/E as proof mechanisms for this

[brentzundel]

Unless you can also demonstrate how to do zero-knowledge proofs and selective disclosure with JWTs and JWEs, what you are proposing is a non-starter. The data model we have produced is compatible with many proof mechanisms. This means it is useful in a wide variety of use cases.

The things you wish to use it for, and the formats you dish to support, are not prohibited by the data model. Limiting the data model to your particular formats and proof mechanisms would prohibit a number of other valuable use cases and cause the data model to be unusable by many.

What is not clear to me is why these suggestions are coming at this point. We have published drafts of our work for a long time. If you had issues with JSON-LD being one possible means of representing the data model you should have spoken up months ago.

What I still have not heard clearly expressed is why, in your opinion, verifiable credentials would be better if they were so limited in the scope of problems they might address. Why, in addition to demanding that the data model support your preferred formats (which it already does), do you insist on trying to change the data model so that it prohibits the formats required by the use cases of others?

On Mon, Apr 1, 2019, 05:09 Anthony Nadalin notifications@github.com wrote:

@msporny https://github.com/msporny I'm very concerned about the use of JSON-LD and how proof mechanisms would work, I know how they will work with JWT as this is proven work, the lack of a completed signature and C14N specification is a show stopper. So I'm proposing a step back and being able to represent a VC as a JWT and use the JWS/E as proof mechanisms for this

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/484#issuecomment-478536223, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ5VPwu7ms7jIWAWfwydWonFUoN9fLQ6ks5vcejVgaJpZM4cNMNU .

[nadalin]

@brentzundel Comments can come in at anytime, especially when you transition.

You have to demonstrate that you can actually do the normative things that have been described in the text in an interoperable way. I don't see how that can be done, there is no proposed interoperable way to do zero-knowledge proofs since no mechanism was defined.

[brentzundel]

You have not addressed my questions and I would appreciate very much if you could do so.

On Mon, Apr 1, 2019, 07:34 Anthony Nadalin notifications@github.com wrote:

@brentzundel https://github.com/brentzundel Comments can come in at anytime, especially when you transition.

You have to demonstrate that you can actually do the normative things that have been described in the text in an interoperable way. I don't see how that can be done, there is no proposed interoperable way to do zero-knowledge proofs since no mechanism was defined.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/484#issuecomment-478581236, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ5VP1QbgjrHQD9YM8RrZyXbth5IGOSzks5vcgrvgaJpZM4cNMNU .

[nadalin]

@brentzundel There is only one question in your text which is "Why, in addition to demanding that the data model support your preferred formats (which it already does), do you insist on trying to change the data model so that it prohibits the formats required by the use cases of others?"

Because there is no proof mechanisms that are documented beyond JWS/E for for JWT as this is the only interoperable means of proofing since there is no JSON-LD proof specification

[nadalin]

@brentzundel I have no objection to the JSON-LD model but to mandate that when there is no proofing mechanism is very odd, keep it simple and work with JWTs and if it works with JSON-LD that would also be good

[brentzundel]

That's good to hear. The data model has examples of how it can be used with JWTs, and JSON-LD. There are also JSON-LD examples with both JSON-LD signatures and CL- signatures. Sounds like we've got our bases covered.

Where we may still disagree is in the need for the proof mechanisms that are used with the verifiable credentials data model to also be part of some standard specification. Is that an assertion you are making?

On Mon, Apr 1, 2019, 07:49 Anthony Nadalin notifications@github.com wrote:

@brentzundel https://github.com/brentzundel I have no objection to the JSON-LD model but to mandate that when there is no proofing mechanism is very odd, keep it simple and work with JWTs and if it works with JSON-LD that would also be good

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/484#issuecomment-478586771, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ5VP3RtTqOx1RPFqyfMQR1GVkMKPbCFks5vcg5UgaJpZM4cNMNU .

[nadalin]

@brentzundel I don't think I would say we are quite there yet. Looking for a simple data model that supports JSON JWT as VC and the use of JSON-LD as VC for those more complicated needs

[David-Chadwick]

One mandatory requirement for the simple data model is support for extensibility. The existing type mechanism does that (and this was the original topic of this issue, not proof mechanisms) in a way that is not dependent upon JSON-LD.

[brentzundel]

My apologies for not fully understanding.

Your second sentence is either missing the subject, or is itself the subject and is missing the preposition.

My intention with that statement is not to criticize your grammar, but to let you know that I don't want to put words in your mouth and possibly assume a meaning you didn't intend.

I think we may be getting closer to a point of common understanding and I don't want to jeopardize that by interpreting your statements incorrectly.

On Mon, Apr 1, 2019, 08:19 Anthony Nadalin notifications@github.com wrote:

@brentzundel https://github.com/brentzundel I don't think I would say we are quite there yet. Looking for a simple data model that supports JSON JWT as VC and the use of JSON-LD as VC for those more complicated needs

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/484#issuecomment-478598932, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ5VP7RSWYYm48Whw7NRNMcaBD173Pk4ks5vchVugaJpZM4cNMNU .

[brentzundel]

@nadalin This issue was raised to bring up the following points:

1. "Should not be forced into JSON-LD as the type data model"
2. "should allow for JSON models such as JWT/CWT."

These points were addressed:

1. "using the JSON-LD type system for this data model does not force any implementor to use JSON-LD"
2. "JWT/JWS are fully compatible with the type system specified"

You then add: " I'm very concerned about the use of JSON-LD and how proof mechanisms would work" While this is certainly a valid concern (as it stimulated quite a conversation here), @David-Chadwick was correct when he pointed out: "The existing type mechanism does that (and this was the original topic of this issue, not proof mechanisms) in a way that is not dependent upon JSON-LD." @nadalin If you would like to continue conversation around proof mechanisms, perhaps Issues #486, #487, #489, or #490 may be better.

If there are points related to this issue that you feel have not been addressed, please let us know.

[msporny]

@nadalin wrote:

I'm very concerned about the use of JSON-LD and how proof mechanisms would work

Since the title of the issue is "4.3 Types" and your original issue was about the type system, and as @brentzundel has stated, there are other issues you have raised about Proofs, then I'm going to try and focus on the original issue you raised (and follow up on the proofs stuff in the other issues you raised that are specific to proofs).

@nadalin wrote:

Should not be forced into JSON-LD as the type data model

The JSON-LD type model (coupled with Section 4.2) basically states that you use type to express the type and you use URLs (or anything that maps to a URL) as the value(s).

Can you explain, in concrete terms (or via an example), the specific issue you are concerned about. How would a JSON-based Verifiable Credentials processor be forced to use a JSON-LD library in this case?

this should allow for JSON models such as JWT/CWT.

The specification allows for JSON, JWTs, and CWTs. Can you explain, in concrete terms, how the use of JSON, JWT, or CTWs are prevented? What could you do before that this section specifically prohibits?

There are many parsers and verifiers out there today for JWT/JWS

Yes, that is true, and the specification acknowledges that and supports embedding of VCs in JWTs, secured by JWS. Can you explain, in concrete terms (using an example), how the use of JWS/JWT would be prevented?

[nadalin]

The JWT parsers out there that I know about can't parse the JSON-LD types, thus a JWT "vc" would be restricted to JSON types, as long as this restriction is made I see no issues, but that is not the restriction today in the specification.

[dlongley]

@nadalin,

The JWT parsers out there that I know about can't parse the JSON-LD types, as long as this restriction is made I see no issues, but that is not the restriction today in the specification.

Could you please give a very specific, concrete, JWT example of where a problem would occur that your suggestion would address? Without being able to see such an example, it does not seem to many in the group that there is a problem. We'd be interested in exploring ways to help to resolve a problem but we first need to understand it through a concrete example.

[nadalin]

A JWT parser would expect this as a claim:

{"Address":"Microsoft Way", "postalCode":"98052"}

And not this:

"address": {

    "@type": "PostalAddress",

    "addressLocality": "Colorado Springs",

    "addressRegion": "CO",

    "postalCode": "80840",

    "streetAddress": "100 Main Street"

  },

[David-Chadwick]

We have an example of address in "Example 36 A credential uniquely identifying a subject" and it is not like the above. Furthermore we are using schema.org properties.

[nadalin]

@David-Chadwick JWT Parser would not understand that same issues as I my example

[dlongley]

I put this into jwt.io :

{
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "jti": "http://example.edu/credentials/3732",
  "iss": "did:example:abfe13f712120431c276e12ecab",
  "iat": "1541493724",
  "exp": "1573029723",
  "nonce": "660!6345FSer",
  "vc": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "type": ["VerifiableCredential", "AddressCredential"],
    "credentialSubject": {
      "address": {
        "type": "PostalAddress",
        "addressLocality": "Colorado Springs",
        "addressRegion": "CO",
        "postalCode": "80840",
        "streetAddress": "100 Main Street"
      }
    }
  }
}

It successfully produced this JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJqdGkiOiJodHRwOi8vZXhhbXBsZS5lZHUvY3JlZGVudGlhbHMvMzczMiIsImlzcyI6ImRpZDpleGFtcGxlOmFiZmUxM2Y3MTIxMjA0MzFjMjc2ZTEyZWNhYiIsImlhdCI6IjE1NDE0OTM3MjQiLCJleHAiOiIxNTczMDI5NzIzIiwibm9uY2UiOiI2NjAhNjM0NUZTZXIiLCJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJBZGRyZXNzQ3JlZGVudGlhbCJdLCJjcmVkZW50aWFsU3ViamVjdCI6eyJhZGRyZXNzIjp7InR5cGUiOiJQb3N0YWxBZGRyZXNzIiwiYWRkcmVzc0xvY2FsaXR5IjoiQ29sb3JhZG8gU3ByaW5ncyIsImFkZHJlc3NSZWdpb24iOiJDTyIsInBvc3RhbENvZGUiOiI4MDg0MCIsInN0cmVldEFkZHJlc3MiOiIxMDAgTWFpbiBTdHJlZXQifX19fQ.8rbBT3ejLrK5o4QUIDbtf90AzLnshU4TAQDOwrEAW6M

The HMAC secret used was test. There did not appear to be any problems.

cc: @awoie, do you think there are any problems here? I'm under the impression that JWT parsers would not break on a "vc" JWT claim and the above parser certainly works. My understanding is that JWT parsers don't do anything with whatever JSON lives under "vc" and that is handled at another layer entirely.

[nadalin]

@dlongley its ignoring the "vc" as it does not understand, my point is that a JWT should be able to understand and process a "vc" but there are restrictions on the what a "vc" would look like

[nadalin]

@dlongley the JWT claim data model should also be allowed data model for "vc"

[dlongley]

@nadalin,

my point is that a JWT should be able to understand and process a "vc" but there are restrictions on the what a "vc" would look like

Is this the same issue as #520, where we've stated that the group expects that "vc" will be registered as an IANA claim? If so, can we close this one as a duplicate?

If not, can you explain what parsing issues you're concerned about? Providing some minimal, runnable code that demonstrates the issue would help the group understand the best. The data model spec provides encoding and decoding rules for the "vc" claim in the JWT and JWS Considerations section.

the JWT claim data model should also be allowed data model for "vc"

There are two ways that the JWT claim data model can be used with a JWT. The first way is by far the simplest, which is to simply use it like you do today with JWTs. You can always include other JWT claims along side the "vc" claim. This allows the same JWT centralized extensibility model (of updating the IANA registry) to be reused as it is today, without any changes.

The second way is to use the decentralized extensiblity model provided by the VC data model and @context. You can create an @context that defines the mappings from whatever set of JWT claims you wish to use and include that in the @context array in the "vc" Verifiable Credential JSON. Then you can use those defined JWT claims within "vc" itself.

Both of these mechanisms can be used today without any changes to the VC data model spec.

[nadalin]

@dlongley There are thousands of sites using the JWT claim data model, the "vc" data model should alternatively allow claims to be defined per the JWT data model for claims. So this way the "vc" claim could be processed by the JWT processors in full. I understand there will still be a need for more complex claims and thus then need for the JSON-LD model but lets make it easy for the simple cases and allow the existing JWT claims and the claims defined in the IANA registry to be used ASIS

[dlongley]

@nadalin,

There are thousands of sites using the JWT claim data model, the "vc" data model should alternatively allow claims to be defined per the JWT data model for claims. So this way the "vc" claim could be processed by the JWT processors in full. I understand there will still be a need for more complex claims and thus then need for the JSON-LD model but lets make it easy for the simple cases and allow the existing JWT claims and the claims defined in the IANA registry to be used ASIS.

My response above covered two ways to do this. For JWT users, they can use decentralized extensibility and/or more complex claims by putting them into a VC underneath the "vc" JWT claim in conjunction with the existing JWT claims model without any changes. If users would like to use the JWT data model inside of a VC or with an alternative proof mechanism, they may use the decentralized extensibility and interoperability mechanism "@context" to put those claims into a VC. I believe the spec enables this today.

[nadalin]

@dlongley I don't think this will work without changes to specification

1. No JSON-LD statements would be allowed
2. No @context allowed
3. Document JWT claims allowed
4. JWS/E stated as proof mechanisms
5. and I'm sure there will be other things that need to be documented to allow a JWT to be claim

[stonematt]

From VCWG call on April 30, 2019: RESOLVED: The WG believes that the type system described in the specification does not require a JSON-LD processor to be used and the concerns raised in issue #484 have been demonstrated to be expressible in JWTs using the VC Data Model in a way that is both conformant with JWTs as well as other expression mechanisms. No technical examples have been provided that demonstrate that the type system used for the Verifiable Credentials Data Model either 1) requires a 8:30 AM JSON-LD processor to process, or 2) causes any known JWT library to fail to process a JWT containing type information (or any other known markup used in the Verifiable Credentials specification). No changes should be made to the specification.

[stonematt]

From VCWG call on April 30, 2019: RESOLUTION: The WG has considered the proposals raised in Issue #484 and continues to support both JWTs and JSON-LD in the specification, continues to support the use of @context as it exists in the specification today, supports any valid JWT claim expressed in a JWT-based serialization, and supports the use of JWS with the specification. The WG has discovered no technical reason that JWE cannot also be used to encrypt data expressed in the specification. Issue 8:32 AM #484 should be closed with no changes to the specification.

[burnburn]

The outstanding request by @nadalin to mandate support by all implementations of the JWT format will be tracked by issue #634. Closing.