Propose verifiable-credential+ld+json media type

[OR13]

---

Preview | Diff

[OR13]

Points back at application/credential+ld+json... related to the debate that is not resolved on #1014

[TallTed]

This makes me think (again) that
IF we're going to have media types for both verifiable and unverifiable credentials
application/verifiable-credential+ld+json
(hyphen, i.e., parallel type to application/credential+ld+json)
should instead be
application/verifiable+credential+ld+json
(plus, i.e., subtype of application/credential+ld+json)

[msporny]

I'm approving as something like a +0.5, while noting that we don't really need this media type. It's a nice to have and makes the spec "complete" from an academic purity standpoint. I expect developers will get media types wrong, and in that case, we should have backup processing rules to make sure that the thing they tag as a "verifiable credential" actually does contain a proof of some kind. Never trust the media type by itself.

[mprorock]

as @OR13 noted, we need #1014 resolved before we can appropriately build on it

[msporny]

Minor nits, mostly. As I mentioned above, I'm a +0.5 on this PR (but found errors upon further review as a part of PR processing).

The big outstanding question is whether or not this media type is necessary given that a proof can ride along w/ any JSON-based media type. I can see the argument for why it would be good to have a media type that is more specific, as long as implementers don't blindly trust that media type anywhere. IOW, implementers should be suspect of anything claiming to be a application/verifiable-SOMETHING and MUST run verification algorithms to determine if the media type is valid or not for the associated data.

Additionally, we should use the official IANA registration template in these sections (or at least include all of the information that goes into the template). That can be done in a future PR if the concern is turned into an issue.

[iherman]

It is not my place, as a W3C staff contact, to formally object, but, with my staff contact's hat put down, I think this direction is wrong. As I expressed in #1044, and as it was argued by, say, @dlongley on the F2F, having verifiable-credential+ld+json (as opposed to verifiable+credential+ld+json) seems highly unnatural to me.

[OR13]

@msporny I took your change suggestions, are there there any other changes your are requesting at this time?

[OR13]

@iherman @TallTed can you point to any examples (that have been successfully registered with IANA) that support your position?

[TallTed]

This makes me think (again) that
IF we're going to have media types for both verifiable and unverifiable credentials
application/verifiable-credential+ld+json
(hyphen, i.e., parallel type to application/credential+ld+json)
should instead be
application/verifiable+credential+ld+json
(plus, i.e., subtype of application/credential+ld+json)

[msporny]

@msporny I took your change suggestions, are there there any other changes your are requesting at this time?

No other change suggestions. I will note that there are others objecting and I find their arguments worth considering.

Speaking as the Editor of the IETF multiple suffixes spec, @iherman and @TallTed are both technically correct... + should be used instead of - ... then again, there is nothing to say that you must do it that way.

I'll also note that @dlongley's concerns about this media type not being necessary are also correct... it has yet to be defended why we must have this media type. What use case or security characteristic does it achieve (other than being a more accurate way to refer to a VC with a proof, where you shouldn't only trust the media type in that situation)?

My approval is regarding the concept of having a more specific media type and not the actual media type string -- that still needs to be debated and we should raise an issue to have that discussion.

[OR13]

@msporny should we ask IETF regarding verifiable+credential+ld+json ?

does this no imply that +credential is a valid suffix?

[TallTed]

[@OR13] can you point to any examples (that have been successfully registered with IANA) that support your position?

The multiple-plus-signs RFC has not yet been approved, and so far as I am aware, we are the first and only group actively pushing to register such media types.

So, no, nobody can point to "any examples (that have been successfully registered with IANA)".

That said, I am quite comfortable with my position on how media types work with the single-plus-sign, and the RFC-in-process was carefully written to work the same way with multiple-plus-signs, so I am equally comfortable with my position on how media types (will) work with multiple-plus-signs.

does this no imply that +credential is a valid suffix?

NO. Absolutely not. Nothing in anything that has been written says that application/credential is being defined nor registered, which would be required for +credential to be a valid suffix.

If you meant to ask whether application/verifiable+credential+ld+json implies that application/credential+ld+json is valid -- i.e., that +credential+ld+json is a valid suffix -- then, the answer would be yes.

Much of which once again supports my request that all discussion of media types use the FULL value, including the application/ prefix, and not abbreviations of any sort, even if such abbreviations might be recommended for in specific locations like the JWT cty and typ values.

[OR13]

@TallTed So assuming we registered:

application/verifiable+credential+ld+json

Would it be possible for the same exact bytes (with a proof member) to be described by content-type either application/verifiable+credential+ld+json or application/credential+ld+json ?

Seems the answer would be yes if @dlongley 's argument is accepted here #1014

Is this consistent with how you think the registration should work?

[iherman]

@TallTed So assuming we registered:

application/verifiable+credential+ld+json

Would it be possible for the same exact bytes (with a proof member) to be described by content-type either application/verifiable+credential+ld+json or application/credential+ld+json ?

I am not @TallTed😀 but I believe the answer is yes. And this is o.k.: a verifiable credential is a credential, so if a receiving end can only handle a credential (i.e., it cannot check the proof) by doing something useful with it (e.g., displaying it to a user) then this would be perfectly fine.

Seems the answer would be yes if @dlongley 's argument is accepted here #1014

Is this consistent with how you think the registration should work?

[msporny]

@OR13 wrote:

@msporny should we ask IETF regarding verifiable+credential+ld+json ?

The request would be routed to the MEDIAMAN WG and then, almost certainly, to me since I'm the Editor of the multiple suffixes WG draft. :P

Yes, we should ask... but only once we decide what we would prefer to do.

@iherman @TallTed can you point to any examples (that have been successfully registered with IANA) that support your position?

The existence of the IANA structured syntax suffix registry, established by RFC6838, Section 4.2.8: Structured Syntax Name Suffixes, establishes the examples for the approach that both @iherman and @TallTed are proposing:

https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml

If we take the structured suffix route, the media type should be application/verifiable+credential+ld+json with the following (most specific to least specific) fallback processing order:

1. application/verifiable+credential+ld+json, otherwise
2. +credential+ld+json structured syntax suffix, otherwise
3. +ld+json structured syntax suffix, otherwise
4. +json structured syntax suffix.

Note that neither +ld+json nor +credential+ld+json are registered structured suffixes at present until the multiple suffixes draft is done. We expect it to enter Last Call during this upcoming IETF, so it's safe to say that we'll be able to register those suffixes before we need to go to REC.

That said, the thing that gives me pause is application/verifiable -- which could be, but VERY debatably, viewed as a media type for Data Integrity... which I've already said we shouldn't register until we have way more implementation feedback. It's also unclear to me if we should separate the "verifiable" part from the "credential" part... I'm concerned that the WG hasn't done enough attack modelling on that aspect of our work (this argument is supportive of @mprorock and @OR13's position, IIUC).

IOW, it feels like application/vc+ld+json might be better, with no auto-hierarchy linkage to application/credential+ld+json other than in the media type description. That is, we break (on purpose) the linkage because we're afraid of the security ramifications of AUTOMATICALLY processing a VC as a application/credential+ld+json -- and I fully realize that those fears are completely unfounded and undefended at this moment in time, which is why I'm only a +0.5 on this PR.

Just sharing some thoughts.

Speaking as the Editor of the IETF MEDIAMAN WG Multiple Suffixes specification, both @iherman and @TallTed are technically correct, I believe:

CITATION: Futurama S2E11 - How Hermes Requisitioned His Groove Back

[TallTed]

application/verifiable -- which could be, but VERY debatably, viewed as a media type for Data Integrity

I would suggest NOT registering application/verifiable as a media type for Data Integrity. You might consider application/intedatagrity (an intentionally ugly portmanteau) IFF this media type encompasses all Data Integrity media types, i.e., the set of all application/intedatagrity documents includes all Data Integrity serializations, and optimally if there will be no application/intedatagrity+SOMETHING supertypes.

we're afraid of the security ramifications of AUTOMATICALLY processing a VC as a application/credential+ld+json

Sometimes, we realize in the weeks following a F2F that some resolutions made there were made in error, sometimes because we're trying so hard to make decisions within the limited time of that F2F. The resolutions about the "base media type" for Verifiable Credentials may be such erroneous resolutions, which I'm coming to think based on my consideration of this pull request.

Media Types are meant to provide strong hints to handling applications and users of what can be done with a given document, and how... but they cannot and should not be treated as sanitizers or protectors!

[iherman]

The issue was discussed in a meeting on 2023-02-28

• no resolutions were taken

View the transcript

1. Add normative requirements regarding media type and proof (pr vc-data-model#1014)

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

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

See github issue vc-data-model#1044.

Brent Zundel: There is a long conversation in the PR, goal of this meeting is to hash out what different sides of debate are, and can then try to come to proposals, recommendations on how to move forward..

Manu Sporny: There are a couple of threads for this discussion. One of the threads is "hey, we should have a media type for unsecured credentials and we should have one for secured ones. Those are the two classes we should have.".
… "If we are going to do that then the unsecured credentials should have no securing mechanism in them." That's the argument for application/credential+ld+json MUST NOT or SHOULD NOT have a proof property in it..
… The other argument is application/credential+ld+json has an extension mechanism and one of those might add a securing mechanism in it and we can't predict what mechanisms other people do, there might be new ones people define in the future and the language can't stop that from happening even if we put text in the spec..
… Even if we say you can't put proof in there, we can't know all the different mechanisms that might happen in the future. The other part of that argument is, "well, you can have very deeply nested and structured VCs and we already have examples of things that learner records and transcripts that might have badges, workforce skills credentials, things that have embedded proofs in them and that's a valid use case.".
… Potentially the outer envelope is not secured but the inner ones are..
… So that's kind of the argument for "they may contain proofs"..
… So we're looking at application/credential+ld+json either: "MUST NOT/SHOULD NOT have proof" or "MAY HAVE proof"..

Michael Prorock: I think that's a reasonably good summary, in my mind, it's a more fundamental question. What is a credential? What makes it a verifiable credential?.
… The way I think of it, once you add a signature, it goes from credential to verifiable credential. Once I see application/credential+ld+json, that's a credential, is an input type..
… once you sign it... it becomes a verifiable credential. We can define what goes into the process, what makes something a VC, and if we can drive that line, we should do that. We can't cover non-compliant stuff w/ the spec, but we should cover cases that we know of..

Dave Longley: I think it's good to avoid confusion where we can, we have to be careful about avoiding confusion when we're talking about secured vs. unsecured or trusted vs. untrusted data... the recipient of the data needs to have an expectation about what they're receiving. They can't just accept whatever the sender sends, that opens the door to potential vulnerabilities..
… Another thing to consider around type is that a VC can be seen as a subtype of credentials, that concept allows for different use cases. Different parties might care about different types of credentials or not. If you have a VC or a credential, a digital wallet can display both..
… People might want to accept things that accept VCs or credentials and add proofs -- so proof chaining, timestamp proofs, and we should be careful to not close the door to innovation, but we should be careful to think that we /can/ close that door. If we put in prohibitive statements, someone will figure out a way to get around it if it gets in the way. For example, someone could do a proof2 field to get around something that says that proof isn't allowed..

David Waite: Some of this may be defining the behaviour when you have multiple proofs by default, I can remove one of the proofs and it's still verifiable, just with less mechanisms..
… The guidance on what to do when there are multiple proofs -- pick your favorite one, do them all for higher assurance, that would be helpful for this discussion, proofs can be dependent on other proofs as well. I have a proof that is protecting other existing proofs, those can't be removed. So some of the assumptions about difference between VC and credential and having proofs, really are in the eye of the verifier..
… Some of the idea here is "if I have something like a JWS wrapping an external proof, and the proofs inside, what are the semantics that people should assume?" If we can't provide semantics that have value, maybe it's not legal in that case..

Michael Prorock: The PR here is explicit around one line related to application/credential+ld+json media type. Those of us that are planning on using that tend to feel strongly, either this is input into something that gets linked data signature, or have external signature... not sure why we would application/verifiable-credential* or some structure that signifies that you have proof there, additional semantics, etc. Avoiding the fact that we can be clear here bothers me, frustrating to me that we can't be explicitly clear about desire to just have credential format w/o proof in it. There are representations that have proof block in there, media type used in cty/typ or other use cases..

Manu Sporny: So I want to agree with what David Waite was saying..
… That the difference between a VC and a credential is in the eye of the verifier. I think that's interesting there, I don't know how I feel with that as an absolute statement, but that resonates with me. There could be a VC with multiple proofs on it, but the verifier only wants to check 2 of them..
… Maybe one is BBS, one is post quantum, one is ECDSA..
… The verifier in that case may only case about ECDSA. They may choose to ignore the other proofs ... or they may choose to look at a proof further down the tree..
… Mike, to look at the use case that you highlighted. ... Here's a concrete use case. If I have a learner record in the education space. The outer thing has no proof, but the inner one has all the classes I took this year and there are class descriptions and skillsets all with proofs..
… Is that thing with 50 proofs at the second level ... is that top level thing a credential or a verifiable credential?.
… You could argue this. I think it's problematic ... I think the PR language doesn't seem to give us an answer for that use case..
… I think it doesn't give us an answer for that use case or use cases where there are other securing mechanisms used. And ultimately, it's up to the verifier to figure out which proofs it cares about..
… It might be then that sometimes different mechanisms determine whether it's viewed as verifiable or not. It's the compound / complex objects that have signatures at the leaves that could be impacted negatively by this language. If we can be more specific we should be..
… Mike's argument for having two different media types for verifiable vs. credentials resonates with me to communicate more specific media types for what I mean..
… Remember, we have application/credential+ld+json which means you can process as JSON, JSON-LD, or as a credential in the VCDM..
… We have that concept..

Dave Longley: media types are not necessarily the right tool to make sure that something is an input to an API. The media type is a way to identify the type of content and how it would be parsed and used, regardless of what API you're using it in. It's a more encompassing thing, not for just one particular use case, one particular API, it's not the right tool for accomplishing that..

Michael Prorock: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept etc. of course multiple use cases.

Dave Longley: That said, APIs have their own shape, can provide their own restrictions, you can do that, that's not a problem and that might be the right way to define that, you can do that via API schemas to accomplish that goal..

Kristina Yasuda: Manu's comment confused me. I do not understand the concept of top level, secondary level proofs, one of the things we did in data model v2 is we separated data model in how we sign/secure it. The notion that something that conceptually is not supposed to be signed can have this proof is very confusing to me..
… That's a use case we need to pay attention to -- is that a valid use case? We have proof in data model, we should move it down to proof formats. I don't think anything related to signatures belongs there..

Michael Prorock: Big +1 to what Kristina said, building on that, we have a good model if we accept this PR, core data model defines what a credential is, and how different specifications might process that... what's expected, in VC-JWT there is a clean way of specifying media types, what to expect when, JWS, or something COSE related, since we have a nice data integrity spec, perhaps we should put media types w/ proofs in a credential, people know how to deal with that information..

Manu Sporny: To address Kristina's concern. We have a concept here -- and JWTs deal with it differently. With Data Integrity proofs, you can have documents that nest other documents and each can nest proofs at every layer..
… We have examples like learner records where that's a reality. Talking about it like "are we going to allow it or not" isn't the right framing because it's already a reality today. It doesn't matter if this group says that structure is illegal, people already find it useful and do it..
… They don't have to base64 at each level and things of that nature..
… We do need to get to the bottom of that and making stuff like that illegal would be a much bigger issue than just this PR..
… The other thing we should consider is that people might use a VP proof and then put a JWT on top of that. I know some people don't want to see that happen, but others might. Given the way things are going in the ecosystem it's probably inevitable that we'll see things like that..

Kerri Lemoie: Learner record spec from 1EdTech doing the embedded VCs that Manu described: http://www.imsglobal.org/spec/clr/v2p0/.

Manu Sporny: Saying proof doesn't belong in the core data model and we should put it in Data Integrity, etc. then we shouldn't be making it illegal to include a proof either. That would be a weird layering violation..
… I think this is us thinking that we have the ability to use a media type to enforce something that people will probably ignore if we write the wrong thing here. I think if we say that the application/credential+ld+json must not have any securing mechanism in it, people will ignore that, the use cases are valid..

Dave Longley: big +1 to what manu said... if we moved proof into data integrity, it would further undercut case for restricting credential+ld+json in this PR, you wouldn't have anything to point to to do it. We should embrace the subclass concept. I'm tagging media type that's specific... another thing to have a less restrictive media type. To provide an analogy -- you can have applications that have rectangles, application accepts it... squares are a more specific type of rectangles... you should be able to use your rectangle library on a square. That's ok, that's what subclass mechanism gives us..
… We have an extensible data model, people will want to know why we added prohibitive statements about use cases they want to do in the future..

Kristina Yasuda: To clarify -- not questioning legitimacy of use case where there are nested data integrity proofs -- what I'm not understanding is credential that is conceptually not supposed to be signed, including a proof property? That's what clearly separates credential from verifiable credential. Let's not completely remove proof from data model, remove it from section 4 to section 6..

Michael Prorock: +1 Kristina.

Kristina Yasuda: Imagine a JSON structure that includes proof property... and that is signed by JWS... if that enters JWS processor, that doesn't understand proof claim, it'll ignore it. In which case, signature is entirely being ignored, which I'm concerned about. Is there a way to resolve that? Happy to hear solutions..

Michael Prorock: No one is saying these are not valid use cases, we want a clear and valid media type.
… Wanting a media type that doesn't have an embedded proof in it, that's a valid use case as well..

David Waite: In the spec we talk about embedded proofs and external proofs, way to state the same thing... embedded proof is a way to extract proof and recanonicalize to create an external proof over the document. It comes down to giving recommendations --- if one proof is chaining, pointing into another, you cannot express outer proof w/o inner one, but you can strip off outer proof, so when people embed a data integrity protected VC inside a JWT, they need to understand that they're requiring twice as much security processing logic... that may affect full stack decisions, or they could just discard the JWT and send credential and data integrity around and they need to decide if it's appropriate or not. If we do have it, we should have a SHOULD NOT with guidance..

Dave Longley: There are going to be many applications that can accept a credential whether or not it has a proof attached to it, important that base media type supports that... if there are other applications that want to have a media type that specifically says "this property is not allowed in this media type" - I think we can do that, but I recommend against it, I don't think it's a good idea. I don't think we should call that out on the base media type. Maybe have base media type to be superclass of other things, someone could create a media type for their other applications, can't have specific property..
… I don't think anyone would want to create 10 different media types for data they don't want their applications to accept, media type isn't the right tool for that..

Paul Dietrich: +1 dlongley.

Dave Longley: "What if this verifier receives something where a signature has been stripped?" -- verifiers need to know what to expect from a holder. They will know what proofs they need to look for, they need to know which issuers to trust, how many signatures to expect, etc... we should remember that we're defining a base data model here, there are things that people don't necessarily process in a credential... base media type that's a super class allows that to happen, I don't think there's a problem there..

Kristina Yasuda: interesting - i though in the open world model, any proof type can enter verifier's system.

Kristina Yasuda: yes, but what they accept is up to them.

Manu Sporny: I think we need to look at the PR. The PR is specifically talking about the application/credential+ld+json and saying that it can't have proof in it..
… Mike, I think you're talking about something else, a media type for a verifiable credential and at this moment in time I agree with you. I definitely agree with JWTs there because it's a base64-encoded dotted string, not JSON..
… That's not true of the Data Integrity secured VCs though..

Kristina Yasuda: @dlongley if verifier only supports JWS it will not know it accepted DI proof signed as JWS, so they can't even make a decision whether to accept or not.

Manu Sporny: So I think the thing you mentioned is a different conversation and that I agree with you more over there, than on this PR. This PR says, we're going to single out this one property and makes it illegal..
… David Waite's SHOULD NOT makes it a little closer, maybe we can do that, but lots people in the ecosystem might just ignore it. I think a lot of people will want to back into what Dave Longley is talking about and that the verifier is going to know what it's expecting..
… Otherwise you're allowing the attacker to choose the attack on your system. You can't trust the media type that the attacker is sending to you. You can't trust that the attack is peeling off a proof, etc. You have to know what you accept..
… You can't trust the incoming media type, the attacker gets to choose it, you can't trust that the thing has the right number of signatures on it, because you can't trust that as well. This goes back to David Waite's comment that the verifier gets to decide what the valid thing is..

Ted Thibodeau Jr.: +1 manu.

Manu Sporny: I think we're trying to use media types to signal things that we shouldn't rely on, it gives power to the attacker..

Dave Longley: +1 manu.

Michael Prorock: I don't think anyone is disagreeing on the multiple layers on security checks, not trusting inputs, I would hope all of us in this group are familiar with those concepts..

Dave Longley: kristina: if the verifier supports JWS then if the JWS proof verifies, they are happy, they don't have to care about the DI proof..

Kristina Yasuda: dlongley: i don't agree.. not validating proof/signature is one of the biggest attack vectors (ignoring == not validating here). security analysis needed to say "they don't need to care". Proof by the issuer has a very important meaning in VC ecosystem - verifier ignoring it undermines trust model of three party model.

Dave Longley: kristina: that's the two-party model :) ... verifier needs to know what they accept and what they don't.

Kristina Yasuda: dlongley: nope, not two party model :).

Michael Prorock: What I'm concerned about is saying that something should not have a proof in any way shape or form, perhaps from a consensus standpoint we end up in SHOULD NOT. If we want to think about a variety of things, no one here wants a proliferation of media types for every options, No one is asking for a proliferation of business rules defined in the spec. If it is implicitly confusing that receives a proof in it, or embedded in a VC-JWT, what proof type comes first. If we don't have a clear way of saying: "Don't do this, you're going to confuse the user"... it's highly concerning to me. If we leave it up to verifier, certain issuers are going to assume one type of security model might be required w/o clean mechanism to know that they're doing that. Let's try to get explicitly clear about what a credential is before it becomes a VC and then be very clear about that as well..

Tobias Looker: I'm still catching up on this issue, so might have perspective that's invalid -- my interpretation of text in PR doesn't insinuate that it makes embedded proofs illegal, media type doesn't establish any semantics around inclusion of property of what it means. If I sent application/json, and data is customer record, that is at a different layer semantically. Embedded proof might have something secured, media type isn't going to communicate presence or processing logic to do anything w/ that..

Michael Prorock: +1 tplooker.

Dave Longley: +1 i think i agree with tplooker too, but also that it doesn't support the prohibition statement.

Ted Thibodeau Jr.: Media types don't do these things... media types don't say "in this structure of file you can only have X field name". Media types give you the structure of the file so you can deal w/ it's contents. If you feed a .zip archive to Excel, it's going to choke because it doesn't know how to deal w/ that content..

Dave Longley: +1 to TallTed.

Ted Thibodeau Jr.: Vice versa, unzip cannot do anything for you with the contents of an excel file... it's not the structure of the document it works on, the structure is the thing that matters here. Subtypes in the mediatype universe are limited not in what fields they can have and the contents of what they could be... bigger type might allow larger number of rearrangements, smaller more focused might allow less..

Dave Longley: +1 to TallTed.

Ted Thibodeau Jr.: Media types don't care about proofs, or business logic, or anything like that. Trying to make them do that job, we're going to break all sorts of security models. It don't work that way..

Dave Longley: +1 to TallTed.

Ted Thibodeau Jr.: I've said in a number of times, a number of places, people don't seem to understand how media types work, if you don't understand how this stuff works, and we try to spec with it, we're going to break something..

Tobias Looker: Further the point that I'm making, don't think media type should rule out in an extensible data model technology whether or not the member of an element should /shouldn't make something illegal. I don't think media type should reach into the data representation technology and says "this should never exist". I think that messes w/ data extensibility model in JSON..

Dave Longley: +1 to tplooker and TallTed, media type is the wrong tool for this.

Tobias Looker: The media type doesn't convey that, media type doesn't tell you anything about what the media type tells you that... it could just be a string w/ some other meaning attached to it. That's all I take the language to mean in this PR. It doesn't communicate anything about the presence of an embedded proof or not..

Manu Sporny: +1 to tplooker, Tallted..

David Waite: One of the ongoing concerns, we're trying to define an extensible data model to use it in ways that we haven't imagined... even extension points we have, like termsOfUse, if there are extensions that you don't understand, what are you supposed to do as a holder or verifier when you see those?.
… In Holder Binding, one of the big concerns is if I have an outer proof of VC-JWT, and I have an inner data integrity proof of the same object/document, what does that mean, what does it imply in terms of issuer instructions of understanding that?.
… To manu's point, you have to define what sort of verification is expected that issuer expects you to do for verifier to trust that information hasn't been modified. So chained proofs, if that's there, with external proofs and chained proofs, we really need to define behaviour of all of those extension points so people know how to act even if they don't understand what that extension is..

Ted Thibodeau Jr.: can't force that business rule on the verifier.

Michael Prorock: Is there an approach that might work? If media type is used, embedded proof must be ignored by processor by verifier? This is a reasonably complex thing we're trying to say..

Kristina Yasuda: I think we double clicked on statements meant by tobias and tallted -- JWT registered application/jwt -- in header, but you can also use application/jwt in HTTP response to indicate that's the thing being returned... I thought we dug into that at F2F? That seems to be misaligned as well..
… maybe we can discuss thing from Mike Prorock.

Dave Longley: -1 to telling verifiers that the have to ignore a proof.

Brent Zundel: Jump on PR and try to refine some language..

Dave Longley: dlongley: that's more violation of the three party model, IMO.

Brent Zundel: See everyone on the call tomorrow..

---

[msporny]

Suggesting the following course of action, first recorded here:

#1032 (review)

This could be how we get this PR into the spec:

1. Rename application/credential+ld+json media type registration to application/vc+ld+json (with bits of this PR thrown in there).
2. Register application/vp+ld+json as the media type for verifiable presentations. @brentzundel's argument is compelling, anything that contains a VC in it is a VP (whether or not the VP is secured or not, the mere existence of the VC in the VP makes it verifiable).
3. Use @mprorock's PR Add section describing use of media types  #1055 to define exactly what the expectations are around secured credentials and secured presentations, because at the end of the day, that's what's going to drive system behavior (not these unsecured things).
4. DO NOT register application/credential+ld+json and application/presentation+ld+json because they add little value.
5. Speak to the difference between credentials/presentations and verifiable credentials/verifiable presentations in the spec in a non-normative fashion.
6. Think about defining a Credential and Presentation RDF class after we work through 1-5 above.

[jandrieu]

Seems like we should figure out what that media type means before we decide that we are going to define it.

[iherman]

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

• no resolutions were taken

View the transcript

1.3. Propose verifiable-credential+ld+json media type (pr vc-data-model#1034)

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

Brent Zundel: This PR proposes application/verifiable-credential+ld+json as a new media type. This PR is older than MikeP's..
… I want to get Orie to talk about this PR and what the set of proposed changes is and we can go to the queue to see what changes are needed to make this acceptable..

Orie Steele: This PR, 1034, is just a request to register a media type. It doesn't describe normative constraints on the media type, it just says, "Hey, IANA, when our doc is complete we request this"..
… It's also related to RDF classes like Credential types, there's other stuff out there. I agree with Manu's suggestion to shorten the media type, I'd like to merge those. I think this also opens the door for us to use this as the base media type instead of the one we agreed to at the F2F. What is the base media type -- is it application/credential+ld+json or application/vc+ld+json?.
… This PR just gives us a named media type to refer to when we're arguing..
… That's it..

Orie Steele: +1 Manu.

Manu Sporny: I'm in favor of pulling this in with the modification I suggested, even without it I'm supportive. I spoke out against this PR in the beginning, but I'm ok with now primarily because it feels to me that the group can get to agreement on what is required/not required for a VC and getting to agreement on just application/credential+ld+json has been illusive thus far..
… I think if we make application/vc+ld+json as the base media type I think we can all agree that this thing can be secured in general, maybe not all the time..
… This PR takes out all the normative language as well, so this just says there's a media type and there's less to object to..

Orie Steele: This PR never had normative language, it was always just a way to give a name to a concept we have discussed in other issues / PRs..

Manu Sporny: This PR doesn't get into the controversy. To summarize, if we can only get to one media type in the data model this one will be easier, I think..

Brent Zundel: I want to note that these PRs have been well structured to do small simple changes to move us in a general direction. It doesn't say what this thing is, it doesn't say what it is..

Joe Andrieu: Yeah, I think this is a not well-thought through PR. I think we need to know what we're naming before we settle on the name. There is a possibility that this media type might become the base media type. That's a totally different conversation from one that will transform to the base one..

Ivan Herman: +1 to Joe.

Joe Andrieu: These conversations will depend on defining the media type and then the name. I think a PR should have some notion of consensus that we think represents our best current understanding of what the spec is which we don't have and I don't think we should specify it until we know what it means..

Ted Thibodeau Jr.: I want to highlight that there was a difference in what Manu spoke and what was typed in as logged..

Orie Steele: +1 TallTed.

Ted Thibodeau Jr.: That difference is important and the written log is closer to what I would be ok with. This potentially defined media type allows for the possibility of securing the content as opposed to indicating that it is secured..
… I think that's part of the largest back and forth between VC vs. C -- and I'm going to start using those terms because that's what we have been discussing..
… I think this is a good reason why abbreviations aren't necessarily good, VC = Verifiable Credential, C = Credential and one may not necessarily be the other..
… The data structure doesn't need to include proofs it just needs to have a slot that can be filled..

Manu Sporny: This PR doesn't include the definition and I think that's a good thing, because I think we'll have a long walk before this PR can get in..
… This suggestion isn't picking vc vs. c vs. verifiable-credential whatever -- that's a separate discussion..
… This media type, signals that it is a mechanism that can be used to secure a credential. That thing may or may not have a proof, but in the media type section we recommend or outright say that it has to have such a proof / is secured in some way..
… It's not a may / may not have an internal / external proof. It is expected that you have either an external or an internal proof that is securing this document..
… I don't know if that meets your bar, Joe..

Orie Steele: This PR just gives a name to a concept. There are so many things discussing this -- it's reasonable to say there are two concepts and you give names to them to refer to them..
… We already have a media type for one thing and this will give a name to the other concept..

Ted Thibodeau Jr.: -1 to "this means you're expected to have put a proof in there somewhere" unless that proof could be "null".

Orie Steele: In all the discussions, we can continue to evolve and we can new constraints and relationships between these things, in every argument I've seen in the WG people are assuming these media types exist..
… I think it's ok for us to merge this and continue in that journey. We can remove things later if necessary..

Phillip Long: +1 to verifiable credential (however you say it) must have a proof associated with it of some kind. To me, at least that's what verifiable means..

Orie Steele: I think it's a mistake to bring in term definitions for RDF classes or term definitions for spec texts into registration for this concept. I don't think it helps achieve the objectives of making the arguments clearer -- in a way that will coming things and make it harder to get to clarity in the WG..

Ted Thibodeau Jr.: Is "[unverifiable] credential" a subtype of "verifiable credential"?.

Manu Sporny: TallTed, that's a debate we'll need to have..

Orie Steele: I would just like to acknowledge that folks in the WG are arguing as if this is a distinct media type from the other one that we've registered. Those arguments are attempting to distinguish between them and we might find out there is no such need to distinguish, but having this name around is helpful to those arguments..

Joe Andrieu: The evidence you cited actually makes me even more opposed. People are using this term as if it has consensus and that gives it even more imprimatur that we need it. I think the problem is what you're highlighting as your reason for merging the PR..

Orie Steele:

"A set of one or more claims made by an issuer. A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which can also be cryptographically verified. The claims in a credential can be about different subjects." (see https://w3c.github.io/vc-data-model/#dfn-credential)).

Joe Andrieu: I'm trying to push back on these slippery slope adjustments where someone says "we already made that decisions it's in the spec"..
… People don't yet agree on what this means..

Ivan Herman: Just a word of warning -- Orie, you said we've registered things and we haven't registered anything yet. That will only happen when we go to CR when we request for registration. We haven't registered, we have just documented our thoughts, no registration has been done..
… We have to be careful about those words..

Brent Zundel: That's correct..

Orie Steele: ivan is correct, we have "requested registration"..

Orie Steele: in a document that has not yet advanced..

Ted Thibodeau Jr.: "proposing requesting registration".

Orie Steele: ^ that.

Manu Sporny: Just to outline the potential paths forward that I think Ted and Joe are asking for. One of those is to clearly define what the media type does and is used for. I tried to do that before. My request is for Joe to put himself back on the queue to respond..

Joe Andrieu: Is that in writing or verbally?.

Manu Sporny: Verbally, the vc media type is used when you have an expression of the data model that is secure; that is the expectation. You use that media type when you have a credential that's secured..
… That's it for this PR..
… Won't say more to try and get feedback on that..

Ted Thibodeau Jr.: I would not be in favor of that unless we have a type that addresses the other half of the puzzle. You've just described the secured chunk, there is an unsecured chunk that should just as well be expressible in roughly the same format. The only difference between them is the securing part..

Orie Steele: +1 TallTed.

Ted Thibodeau Jr.: If the only way that's defined to express the secured ones -- then we can't express the unsecured ones. Some will be secured and others will not be. We might need a distinct type for the secured or the unsecured. Either we need a super class or two disjoint subclasses..

Orie Steele: +1 to TallTed framing again..

Joe Andrieu: Quick note for TallTed, my understanding is the base media type is the unsecured thing. My sense is that we had that agreement in Miami and this was an additional secured media type. Your definition seems ok, but it triggers for me, what about VC-JWT, is this for any mechanism that has secured a VC?.

Orie Steele: I queued to hopefully answer Joe's question. We're in the core data model spec, the core model is JSON-LD. Both of these have +ld+json at the end and they could be used in the cty header in a VC-JWT..
… There was a slide for it -- there was a question "is proof expected / allowed to be present?" when you see cty with +ld+json. There's no decisions about allowed or forbidden yet..
… The current 1.1 spec says vc+ld+json, proof would be allowed there, you'd expect it to be there if secured with a DI proof and expect it to maybe not be there if using an external proof..
… The spec text says "at least one proof". My interpretation of 1.1, if you had a VC and it could include or not include a proof..
… That's my interpretation of the text today, that's assuming that it would go along with this media type..
… Since this WG can't agree on mechanisms for proofing a credential or 'proof' in a credential, it seems that the group could more easily come to a conclusion on the vc media type requirements..

Brent Zundel: +1 to Orie.

Manu Sporny: +1 to that on how we go about processing that. It's fine if we don't do that we will have to open the can of worms on hierarchy, the relationships between the media types, the + subclass concept, and so on -- that will take a while to unpack..
… It sounds like Joe and Ted, you're asking to move to unpack that. Before I jump into doing that -- I expect that will eat up the rest of this call and a number of other calls, I want to make sure that there will be objections to pulling in any variations of this PR before settling those questions..

Joe Andrieu: Yeah, I think that's right. What this media type means is important to whether or not we should add it..
… The essence of the question I asked about VC-JWT -- is, is the media type that you're proposing here, for vc+ld+json, you said that would be used for secured credentials and I would anticipate that it would include VC-JWT. I talked about a parameterized version of the media type where we parameterize the proof type..

Manu Sporny: JoeAndrieu, that's not what I'm talking about :).

Joe Andrieu: We could have that or not -- if what we're talking about is a single media type with no params, then a definition seems to conflate different forms of securing credentials. Is it for just one form or multiple forms?.

Brent Zundel: I'm wondering if -- speaking ... this PR has concrete text, what concrete changes would need to be made to make it acceptable to merge?.
… If you are objecting to pulling in this PR, is there a concrete change that would remove your objection?.

Joe Andrieu: I think we need a definition, until we have a definition, I can't support this PR. If we pull this in, I think we're moving away from where we had consensus with a converging solution. I think we need that definition..

Brent Zundel: Is there a definition you would support?.

Joe Andrieu: I don't have a definition, it doesn't exist, the PR is too early, we need to have the conversation to generate the definition..

Ted Thibodeau Jr.: I'm not far off from Joe, not a surprise for many of you. It seems clear to me that Manu's expectations that this media type entail the inclusion of a proof are not the same expectations of everyone who is looking at this media type..
… I'm ok with this media type to have box for this proof to go into, maybe that includes something that says the proof is external, maybe it says it has the proof itself..
… The requirement that it be the bytes that make this proof happen is not ok. Then we don't have the whole expressible, just the proven one..

Orie Steele: This PR DOES NOT constrain the media type, and yet... people are objecting based on "hypothetical future constraints"..

Orie Steele: Another note on parametrized media types, they don't play well with reuse in HTTP responses..

Manu Sporny: Let me try and propose some concrete changes. So, Joe, you asked about params -- the answer is that this does not include media type params, so no. That would lead to a lot of objections, it makes parsing harder, etc. those things exist and we can call that question, but I expect people to object..
… This approach is a non-param one..
… I think there is a desire by some WG members to have two potential serializations -- it may be two different media types, I will pretend it's two right now for discussion..
… One is application/credential+ld+json and the other layers on top that is a vc one..

Ted Thibodeau Jr.: the dash vs the plus matters....

Manu Sporny: There is a difference between them. I am proposing that the difference between them is the expectation in how they are used..
… credential+ld+json is expected to not have a proof on it. And some people said it could, but does it forbid proofs or can it be on there? That's a question..
… For vc+ld+json is expected to have an internal or external proof. That's the difference between the expectations around the media type. The debate we're having is about whether proof should absolutely be forbidden but it's really strongly suggested that you don't..

Orie Steele: +1 Manu..

Manu Sporny: For credential+ld+json. For vc+ld+json, I think it's not controversial to say a proof is expected but you don't have to use the proof field..
… It sounds like we're saying we want to have two media types -- if we do that, what's the difference between them?.
… I think that's a question to you, Ted, and Joe..

Joe Andrieu: I'll try and be short. I think what you're proposing Manu is that this is the DI interpretation that can transform back to the base media type. It's not for all secured VCs and it's just one class of them..

Orie Steele: I don't think that is what Manu is proposing..

Manu Sporny: JoeAndrieu, unfortunately, that's not what I'm proposing :).

Joe Andrieu: I think the class you care about is just the DI version. That would free up this conversation quite a bit..
… How would we know if it's some other securing mechanism?.
… The lines are kind of blurry..

Orie Steele: I do agree with Joe's comment that there is confusion regarding the relationship between proof and data integrity... in the core spec..

Dave Longley: It's been challenging to participate and scribe... short thing I want to say, slightly concerned that we might not be using media types properly wrt. expectations for meaning vs. concrete serialization. What media types are meant to do is to express concrete serialization. Whether or not proof field is present, syntactical element, but conceptually, that's a different conversation and doesn't have anything to do with media types..
… We might be able to get to one media type that captures all syntactic elements and then move discussion on how something is secured out of media type space..

Brent Zundel: I think we got much closer on this one -- we had some good discussion, some concrete ideas on the table..
… Thanks for scribing, challenging scribe day. We'll talk tomorrow..
… Thanks everybody!.

---

[OR13]

@msporny I accepted your suggestions, can you please re-review.

[selfissued]

LGTM

[msporny]

Suggested change

	Resources that use the "<code>application/verifiable-credential+ld+json</code>"
	Resources that use the "<code>application/vc+ld+json</code>"

[msporny]

Suggested change

	for the "<code>application/credential+ld+json</code>" Media Type and are
	for the "<code>application/ld+json</code>" Media Type and are

[msporny]

Suggested change

	in Section 11 of [[!RFC7159]].
	in Section 11 of [[!RFC7159]] and [[JSON-LD]].

[msporny]

@OR13 wrote:

@msporny I accepted your suggestions, can you please re-review.

I'm requesting changes, but not because I'm against the direction of this PR.

As @OR13 has mentioned several times now, the serialization rules between an application/vc+ld+json and a application/credential+ld+json media type are exactly the same. We shouldn't have two media types for the same serialization.

The changes requested to this PR are to remove application/credential+ld+json from the specification and replace it with application/vc+ld+json (this PR) as the base media type.

The other alternative is to put an issue marker stating that the group might remove application/credential+ld+json from the specification and replace it with application/vc+ld+json (this PR) as the base media type.

Either of the paths above would be acceptable to me.

[TallTed]

I believe I mostly (maybe entirely) concur with @msporny's comment.

I think it would help if we could enumerate the differences between our proposed subtype (application/vc+ld+json) and its supertype (application/ld+json) that make our subtype valuable and worthwhile. Exactly what would be lost by making VCs use the existing media type, application/ld+json?

This info should help us in our deliberations, as well as our application to IANA, and may even make our documentation clearer.

[dlongley]

The changes requested to this PR are to remove application/credential+ld+json from the specification and replace it with application/vc+ld+json (this PR) as the base media type.

+1

[dlongley]

@TallTed,

I think it would help if we could enumerate the differences between our proposed subtype (application/vc+ld+json) and its supertype (application/ld+json) that make our subtype valuable and worthwhile. Exactly what would be lost by making VCs use the existing media type, application/ld+json?

I think the most important change (but it really only takes one of this sort) is that we require compact form for application/vc+ld+json. I agree mentioning this and other syntactic restrictions above and beyond application/ld+json would be helpful to make documentation clear and with the application to IANA.

[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.

[OR13]

Closing this PR, we will attempt to define a media type for vc+ld+json in a new PR, after the editorial fixes for the section settle.

I will wait to open the new PR until #1062 is merged.