Restrict JSON-LD expression to compact document form.

[msporny]

Addresses PR #779 by limiting JSON-LD expressions to compact document form.

---

Preview | Diff

[OR13]

what is the difference between "expression" and "representation" ?

[msporny]

Historically, I think we've tried to use "expression" to talk about something in the abstract (the data model) and "representation" to talk about something concrete (a serialization). I mixed them up here, and will change both to speak to "representation" -- does that work for you, @OR13 ?

The other option is we could say "serialization". All of this is a bit up in the air given that the JSON section in the spec, while it never really made any sense, makes even less sense now.

[OR13]

Prefer more explicit wording, not sure how the normative statement will be testable in its current form.

[TallTed]

LGTM. Will be improved by @OR13's suggestion and question.

[OR13]

I like this suggested change, #1050 (comment)

But I would also take a change dropping verifiable.

[msporny]

But I would also take a change dropping verifiable.

Ok, dropping verifiable for now since it seems to be more accurate wrt. the media type being described.

@OR13 please re-review and confirm that this is the change you wanted.

[OR13]

"all representations of the data model"... this seems not correct based on F2F day 3 resolution.

We agreed that this only needs to be true for the "base media type" aka

application/credential+ld+json or application/presentation+ld+json

Perhaps this PR changes the requirements for what constitutes a "mapping" to the base media type?

I would prefer for this MUST to be bound to a specific content type, no abstract concepts that have no normative definition.

I feel similarly about other parts of the spec, such as @context or validFrom.

@msporny how can we make it clearer that "not all verifiable credential representations use JSON-LD compact form" ?

[TallTed]

"all representations of the data model"... this seems not correct based on F2F day 3 resolution.

You're taking that phrase out of context. The stricture is on "all representations of the data model described by this specification" which I believe we expect to be few, so your concern seems premature to me.

[OR13]

Resolution #1: 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..

https://www.w3.org/2017/vc/WG/Meetings/Minutes/2023-02-16-vcwg#resolution1

#947 (comment)

I feel credential+ld+json uses "compact form" would be a clearer way of saying the same thing.

Seems the intention is aligned with resolution, and data integrity proofs can indeed use "non compact form" for VCs.

[msporny]

@OR13 I get what you're saying and I think I agree with you. @TallTed you're technically correct, but this might be an area where we can be very specific without giving the impression that we're restricting media types that we didn't mean to restrict.

I'm waiting on the media types discussion to settle before applying the final wording here. We need to understand the outcome of the media type discussions before locking the wording in this section in, which should probably only apply to the ONE base media type.

[TallTed]

I think we would do well by rewording the sentence —

JSON-LD <a
href="https://www.w3.org/TR/json-ld/#compacted-document-form">compact document
form</a> MUST be utilized for all representations of the data model described by

— to —

JSON-LD <a
href="https://www.w3.org/TR/json-ld/#compacted-document-form">compact document
form</a> MUST be utilized for all JSON-LD representations of the data model described by

— if that is indeed what was intended (which I don't think it was).

Given that we're defining the base media type, named credential+ld+json (or vc+ld+json), to which all other representations must be losslessly transformable, I think it would be better to say —

JSON-LD <a
href="https://www.w3.org/TR/json-ld/#compacted-document-form">compact document
form</a> MUST be utilized for all representations of the data model in the base 
media type, vc+ld+json (or credential+ld+json).

[msporny]

Applied a variation of @TallTed and @OR13's language. Fixed in e63c069.

[OR13]

Approving only based on the resolution today, regarding vc+ld+json.

[iherman]

The issue was discussed in a meeting on 2023-03-14

• no resolutions were taken

View the transcript

2.3. Restrict JSON-LD expression to compact document form. (pr vc-data-model#1050)

See github pull request vc-data-model#1050.

Manu Sporny: This one, PR 1050, was just waiting on what we decided today. I'm not worried about this PR.
… We can merge this based on our conversation today.

[iherman]

The issue was discussed in a meeting on 2023-03-14

List of resolutions:

• Resolution No. 1: We will change application/credential+ld+json to application/vc+ld+json to use as the media type for verifiable credentials and add language to the spec that indicates the media type does not signal how the VC has been signed.

View the transcript

1. Media types vc+json+ld vs. credential+json+ld.

Manu Sporny: Could we tackle the PRs about media type first? And I ask because there are about five PRs we could potentially resolve if we get to a conclusion there and we are maybe close.

Ted Thibodeau Jr.: I'm hesitant to go along with changing special topic on the special topic call — might have shown up if another topic is discussed.

Brent Zundel: With those comments, let's stick w/ PRs.

Manu Sporny: I'm wondering — So I've got a proposal for the group and wanting to see if we can get to consensus... seeking feedback on it.
… We have been talking about ... we have decided that there will be one base media type for the VC data model. That's super good and useful.
… Then, we started talking about ... that was application/credential+ld+json as the base media type, unsecured, our base media type. Then we have a number of media types around application/vc+something for secured things but there has been disagreement around the requirement of proof and we were trying to figure out how to do that through media types. We now have a section in the spec for the media types.
… Then Orie raised a really good question — about how these two media types application/credential+ld+json and application/vc+ld+json ... people are arguing that proof is optional in both and we have two media types that describe the same thing. Skipping past a lot of the back and forth.
… I wonder if we can make the base media type application/vc+ld+json and proof is optional in that. Then in the media types section we make internal/external proofs clear and so on.
… The proposal would be for the base media type to be application/vc+ld+json, proof is optional, but we don't say that in the media type registration but in the spec. What do people think?

Ted Thibodeau Jr.: Yes, in general theory, I'm with you.
… The media type for a zip archive doesn't change whether it's password protected, or one or a hundred files, or anything, really. You deal with it as a zip archive.

Dave Longley: +1 to TallTed.

Ted Thibodeau Jr.: In our case, we are dealing with credentials which are verifiable, and the failure could be that proof is missing, or proof fails (you messed up the crypto), or something along those lines.
… It's taken a while to reach that point as a group, we might be a step away where we out to be. That might just be ld+json. I want there to be an explicit difference between vc+ld+json and ld+json.
… There has to be something that a ld+json loses when it doesn't process as vc+ld+json.

Kristina Yasuda: I'm not with you yet, Manu. The proposal I think I made in previous call was well received — can we completely remove proof property from VC Data Model so only media type in main becomes credential+ld+json, so we don't talk about proof property. Then vc+jwt and data integrity can define their own media types vc+??? if needed, is that an option, is that on the table still?

Michael Jones: I'm going to try to react to all three comments.
… I agree with Manu that de-facto, the WG hasn't been able to, for JSON-LD data model, been able to make any distinctions between credential and verifiable credential in the media type.
… The attempts to say that proof must not be present for credential+ld+json have not succeeded, and in order to make progress, I'm willing to see single VC data model be application/vc+ld+json.
… To Ted's comment, I agree that there is and should be a meaningful distinction between ld+json and vc+ld+json, the difference is the required members of VC data model are present and are used in ways specified.

Manu Sporny: Yes, MikeJ, exactly!.

Michael Jones: I think we can agree to that.
… I agree with you that proof property should be moved into securing spec, that's what defines its properties, I don't think that Kristina's comment blocks us from registering the media type, and from brent's earlier comments, if we can unblock the media type registrations, we'll be a good bit further forward today.

Orie Steele: +1 to compact form being a constraint.

Dave Longley: I got on queue to agree with MikeJ — the constraints are the data model — and compact form must be used. any one of those things establishes a specific new constraint, that's the difference.
… with respect to Kristina's comment — if we move proof back into another spec, doesn't resolve particular matter at hand, proof being optional, we'd end up in that situation, those issues are orthogonal. That's a different question from what we're trying to resolve here. We want the base media type to be application/vc+ld+json as everyone else has spoken to.

Phillip Long: +1 that moving the proof to data integrity is a different question and not the one that we're talking about here.

Orie Steele: I agree with the comments from Manu and Mike Jones about application/vc+ld+json media type. I also am not sure that proof predicate should be removed from core data model context. I want to talk about what's in v1.1 spec, if we can't achieve consensus to change it, it's goin gto stay the same.
… In v1.1, proof is a predicate that exists. There is no definition of Credential (in RDF sense), only Verifiable Credential. The proof types are the RDF classes that the securing formats tended to define. A proof type example would be Ed25519Signature2018. In v1.1 we shipped proof property in core context. In v2.0, we cleaned some stuff up and avoided having to talk about types. If we say base media type is application/vc+ld+json, we commit ourselves to have conversations about proof being in media type.
… It would be good to get agreement on the base media type on what we see in v1.1, there is a higher chance of doing that with application/vc+ld+json, vs coming to consensus on what application/credential+ld+json.

Kristina Yasuda: If you are talking about media type for v1.1, vc+ld+json might be ok, but to use that for v2.0, I'd be against that. To v2.0 is to separate payload from how it's being secured. Saying the base media type is "vc+" — what is the verifiable part of that payload if that's the base media type?
… Does that mean now we'd only have one media type per signed credential that has to express both what is a payload and what is signed? To be more specific, one example I can think of, in SD-JWT, with current separation of application/credential+ld+json — use that as a payload, use SD-JWT to secure it.
… when you're signing, apply digest as defined in SD-JWT and you're good to go. I don't know what that means when we say application/vc+ld+json.

Ted Thibodeau Jr.: First, assuming we continue down this road, how are we going to convince IANA that there will not be a cascade of special definitions of ABC/xyz+ld+json each with their own set of members and usages? I don't have a concrete differentiator, we could say "you have to have these members in order to be a VC".

Orie Steele: partial answer to Ted's question, IANA expects registration for types that use registered suffixes. That is why we define structured suffixes.

Ted Thibodeau Jr.: Consider RFC822 messages and attachments, where media types came from, there is an envelope and a payload and metadata, these things are separate, signature on signed mail, on unsigned main no signature, not mentioned. these are things that didn't require new media types, media types for those things existed in other usages, those media types are applied in enclosures. we're using media types in a way that's not intended to be used, it'll bite us if it's not already doing so.

Michael Jones: My response to Ted will reference https://www.rfc-editor.org/rfc/rfc8725.html#use-typ.

Dave Longley: I wanted to respond to Kristina, differentiating between credentials and verifiable crednetials — to a certain extend, we've made a number of things more complicated than before in ways we didn't get more value out of that complication. The difference might not come through an incompatible syntax. data integrity adds proof, which adds types to a proof property. that fits in w/ existing data model. That other syntaxes might have incompatible syntax, but when that happens, you need a new media type. I think all that's ok.
… I think Mike's on the queue to respond to what Ted said, I'll end my comments there.

Dave Longley: i was also going to say . i don't think SD-JWT will have to change.

Michael Jones: I did want to respond to TallTed's comment... how are we going to convince IANA to say there's not going to be a multiplication of mediatypes *+ld+json, by analogy, there was an RFC written 8725 — JWT best practices, and one of the best practices listed was "Use an explicit media type for every type of JWT object" — explicit typing and that can prevent a confusion for one type of JWT for another. That's part of a more general move in security community.

Orie Steele: +1 selfissued.

Michael Jones: "Use explicit typing" to prevent confusion, not a bug that there might be a multiplication of JSON-LD subtypes, it's a feature, because it enables explicit typing. Using vc+ld+json is an example for explicit typing, that's a good thing.

Brent Zundel: Initial round was prompted by a proposal, folks spoke up for certain aspects, resolve the media type aspects first then continue conversation where it needs to go.
… How would we need to change that proposal to move forward?

Dave Longley: This might be a slight tweak, keep proof where it is right now and figure out if we move it later.

Orie Steele: +1 dlongley.

Kristina Yasuda: I still haven't heard an answer.
… How do we know if it's signed or not?

Orie Steele: In case signing is used — proof is used, RDF says the type... if external is used, then proof isn't there or is ignored and external signing mechanism applies information necessary for signature. So, for JWT, alg secures content type for application/vc+ld+json — and if you look at that content type, youg et back JSON, verify signature in external proof case. If you see proof in data model, and you don't understand it, you ignore it.

Dave Longley: +1 to Orie.

Orie Steele: People might profile away proof property, but there are scenarios where they want it to be present and might want to tunnel secured data in proof. And add external proof format. Short answer is in case of external proof, you're going to verify the external proof and then you get payload... if payload contains internal proof, you might ignore it, or if you do understand it, you verify according to proof type.

Dave Longley: +1 to Orie.

Phillip Long: =1.

Orie Steele: For the record, I don't really care to "block" the "credential tunneling" feature.

Phillip Long: +1.

Kristina Yasuda: Thanks Orie, that makes sense, I think. I'll be ok given that is clearly stated in VCDM. I don't know what concrete proposal language should be, someone could point me to that? I think what I heard was base media type says this is a signed credential using JSON-LD and how to determine how it's signed is specific to signing mechanism, which is fine.
… Make sure that's loud and clear, you have to depend on checking mechanism.

Orie Steele: And the current "proof" section essentially says this already... it says "at least one, proof format"... https://w3c.github.io/vc-data-model/#proofs-signatures.

Dave Longley: +1 to kristina to provide clear guidance.

Kristina Yasuda: For VC-JWT, for example, other specifications can define their content type, credential is signed ... if my understanding is correct, I'm ok w/ direction.

Manu Sporny: (Brent deftly composes a proposal, much like Beethoven writes a symphony.).

Orie Steele: media type vc+ld+json might have external proof, you won't see evidence in internal content type, because external proof is external.
… You could have internal proof, and that would say you have an internal proof. I would avoid trying to smith proof related changes into resolution. We will have to address proof related issues as a group, don't see need to add more language to this particular proposal.

Brent Zundel: Kristina, are you ok w/ moving forward noting that we need to have proof conversation separately?

Manu Sporny: Kristina makes noises of disapproval.

Brent Zundel: Or we could add...

Kristina Yasuda: The media type does not dictate how credential is signed?

Dave Longley: +1 to Kristina.

Orie Steele: +1 to the "media type does not dictate how the credential is signed".

Kerri Lemoie: +1 Kristina.

Phillip Long: +1.

Orie Steele: that is what I was trying to say regarding the current proof section of the spec.

Dave Longley: we should say "to use as the base media type".

Phillip Long: +1 to Dave's suggestion.

Proposed resolution: We will change credential+ld+json to vc+ld+json to use as the media type for verifiable credentials and add language to the spec that indicates the media type does not signal how the VC has been signed. (Brent Zundel)

Brent Zundel: +1.

Michael Jones: +1.

SongPu Ai: +1.

Joe Andrieu: +1.

Gabe Cohen: +1.

Phillip Long: +1.

Shigeya Suzuki: +1.

Orie Steele: +1.

Kerri Lemoie: +1.

Dave Longley: +1 application/ prefix is presumed :).

Manu Sporny: +1.

Kristina Yasuda: 0.

Dave Longley: +1.

Ted Thibodeau Jr.: +1 with application/ :-).

Brent Zundel: This will go out for review before it's officially resolved.
… I'm going to add application/ to be clear that that's what we resolved.

Resolution #1: We will change application/credential+ld+json to application/vc+ld+json to use as the media type for verifiable credentials and add language to the spec that indicates the media type does not signal how the VC has been signed.

See github pull request vc-data-model#1034.

Manu Sporny: With that, I think we can merge Orie's 1034 PR.
… We may / want to modify that PR to just remove the application/credential+ld+json to make it clear there's just one base media type.
… We should do that and that will be 1034. Then 1050 can refer to application/vc+ld+json and we can pull in 1050.
… 1014 I believe gets addressed by this.

See github pull request vc-data-model#1014.

See github pull request vc-data-model#1050.

Manu Sporny: We're going very far towards resolving it at least.

[msporny]

Editorial, multiple reviews, changes requested and made, no objections, merging.