Address Ambiguity Regarding Multiple Structured Suffixes

[OR13]

---

Preview | Diff

[OR13]

@TallTed I don't understand how to implement your suggestion here, I agree its a bit redundant to call a VerifiableCredential a JWT Verifiable Credential....

But we do that with Credential and Verifiable Credential in the core spec, and the core spec says either can be secured with an internal or external proof... so it seems we kinda need to make it clear we are talking about a thing with an external proof (a JWT Verifiable Credential).

[TallTed]

a thing with an external proof (a JWT Verifiable Credential)

I think that would be better called "a JWT-secured Verifiable Credential". The vc+ld+jwt contains both the vc+ld+json (the proof-less, i.e., unsecured, VC) and the external (to the VC, not to the JWT) proof.

An vc+ld+jwt is a W3C Verifiable Credential

Again, vc+ld+jwt is "a JWT-secured W3C Verifiable Credential"; it's a JWT that contains (among other things) a W3C VC. Calling a vc+ld+jwt "a W3C Verifiable Credential" confuses it with a vc+ld+json, which is "a W3C Verifiable Credential".

[TallTed]

I also doubt we will get consensus to say "a JWT cannot be a verifiable credential", either directly or indirectly.

A JWT cannot be a W3C Verifiable Credential, though a JWT may contain a W3C Verifiable Credential. (I'm emphasizing the "W3C" piece here, though I thought we'd already agreed that, as we're working in the W3C VCWG, when we say "Verifiable Credential" here, we mean "W3C Verifiable Credential")

[OR13]

A JWT cannot be a W3C Verifiable Credential, ...

https://w3c.github.io/vc-data-model/#securing-verifiable-credentials

At least one securing mechanism, and the details necessary to evaluate it, MUST be expressed for a credential or presentation to be a verifiable credential or verifiable presentation; that is, to be verifiable.

This specification recognizes two classes of securing mechanisms: those that use external proofs and those that use embedded proofs. An external proof is one that wraps an expression of this data model, such as via a JSON Web Token, which is elaborated on in the Securing Verifiable Credentials using JSON Web Tokens [VC-JWT] specification.

@brentzundel @Sakurann I'd like to establish consensus on this topic, since it keeps coming up.

proof is optional, so a credential is a verifiable credential.

proof can be embedded or external, but when its external, the thing with the proof is not a Verifiable Credential?

How can we possibly continue with such fundamentals not established.

Also thank you @TallTed for your persistence on this topic, it is critical that we resolve it better.

And it is blocking:

• Clarifying credential from verifiable credential vc-data-model#1009
• NIST defines "credential" differently vc-data-model#1047

[msporny]

@OR13 wrote:

proof is optional, so a credential is a verifiable credential.

That doesn't follow, logically. If we continue to use strange language to describe what's going on, there will continue to be confusion.

This group is concerned with the expression of "verifiable credentials"... "credentials", in and of themselves, are not what the group is spending a large part of their time defining... that was the basis for the "let's stop making the distinction between 'credential' and 'verifiable credential' in the specification" decision... because it was leaking into the formal data model (we were arguing over defining a formal "Credential" type, and a media type for an unsecured credential, which no one was planning on using). In short, the distinction wasn't providing any value.

So, the spec primarily talks about verifiable credentials. Verifiable credentials can be secured. You can't presume that just because it's in a VC format, that it's been secured properly, unless you check to see if it's secured or not.

There are at least two ways to secure VCs today that the WG is working on -- external (JOSE, COSE) and internal (Data Integrity). It's the existence of JOSE/COSE (and external proof mechanisms) that makes proof optional, otherwise it would be mandatory on every VC.

proof can be embedded or external, but when its external, the thing with the proof is not a Verifiable Credential?

No, proof (the property) can't be external... it's for internal use only. A VC can be secured using an external mechanism, or using an internal mechanism. Both of those things are VCs, and if both are secured properly, they are "VCs that are secured via DI/JOSE/COSE/etc."

How can we possibly continue with such fundamentals not established.

The fundamentals have been established, but for some reason, people continue to confuse them. So, how can we make the above more clear?

1. This WG has defined a data model for "verifiable credentials".
2. This WG has defined multiple ways to "secure" the VCDM.

[brentzundel]

@msporny I understand what you are saying, and some of it makes sense to me.
It also feels strange to me to say that a secured VC isn't a VC. Especially since the normative text from the VCDM that @OR13 has quoted says plainly that a securing mechanism MUST be expressed for a VC to be a VC.

I would go so far as to assert that it feels unnecessarily pedantic to insist on saying "VC secured by DI/JOSE/COSE/etc." vs just saying VC. It brings me back to the Credential vs Verifiable Credential conversations that we ultimately decided were about a distinction without a difference.

I am honestly curious what harm may come if we say that those things defined by the VCDM are VCs (and they MUST be secured), and those VCDM-compliant things that are secured are still VCs.

[OR13]

@msporny if proofs or security are optional the following is also true:

This WG has defined a data model for "credentials".
This WG has defined multiple ways to "secure" the "credentials", that is to say to produce "verifiable credentials"...

And that is actually what our spec says... right here:

https://w3c.github.io/vc-data-model/#securing-verifiable-credentials

Note the normative language:

At least one securing mechanism, and the details necessary to evaluate it, MUST be expressed for a credential or presentation to be a verifiable credential or verifiable presentation; that is, to be verifiable.

You seem to be disputing this MUST.... I suggest you raise a PR to correct the confusion, so we can review.

As I said before JWT of typ vc+ld+jwt is just as much a verifiable credential as a JSON object of content type vc+ld+json returned by a web server... with at least one proof... regardless of "where" that proof is... could be detached, external, could be in http response headers, etc...

Assuming this normative sentence (which none of us seem to ever read the same way), is actually a requirement.

I would assert that ONLY vc+ld+jwt is consistently a verifiable credential, given that it always contains an external proof...

and given that proof is optional in vc+ld+json....

It would be more accurate to say some vc+ld+json are verifiable credentials and some are credentials.... assuming the normative MUST does not change...

I am willing to help correct this, by updating that normative MUST to say something like:

proof can be omitted and still the JSON is valid vc+ld+json, and 0 proofs (embedded or external) are required to produce a verifiable credential... (kinda rofl even reading this sentence).

... but perhaps it would be better to not touch this MUST, since it is currently the only normative statement in the core data model that tries to prevent alg: none from getting repeated all over again...

VC JWT currently has a lot of language working around this flaw in the core data model.

Perhaps it would be better to clarify that while vc+ld+json can represent both credentials and verifiable credentials (a version of the token / content type confusion attack, see https://datatracker.ietf.org/doc/html/rfc8725#section-2.8)....

similar to how alg none in the (un)protected header, tells you a claimset is not secured...

.... absence of an embedded proof and absence of an external proof, tells you that a credential is unsecured... or in other words... that while the vc+ld+json is valid, it is not.... verifiable... and does not represent a verifiable credential, because it violates the normative MUST....

I'd argue the MUST is untestable... in its current form, so some update here is obviously needed... in order to get to CR.

I look forward to resolving this confusion.

[OR13]

@msporny thanks for the suggestion, I think your wording is clearer.

The questions regarding why we didn't say:

Media Type for identifying a Credential that has been secured using a JWT

Still remain, but they seem like they will obviously be resolved when we eliminate the distinction between Credential and Verifiable Credential in some future PR that will adjust that normative MUST statement...

[msporny]

@OR13 and @brentzundel - I largely agree with a variety of the points both of you are making. Perhaps we just need to rewind to how we got here.

Because we were making a distinction between "credential" and "verifiable credential" in the specification, there was an insistence that we draw that all the way through to the media types and the RDF types. The argument against doing that was that we were going to define media types and RDF types that were largely not going to be used (or over complicated things). So, to avoid that from happening, we just said: "FINE... we'll only talk about 'verifiable credentials'"... which meant NO application/credential media type and NO Credential RDF type. The downside being that it has now created this entirely new set of problems. I'm not looking forward to going through the spec and changing 300+ references to the word "credential".

So, what if we were to NOT get rid of the distinction? Conceptually, there is a difference between a "credential" and a "verifiable credential". IOW, I think the current distinction in the spec is /conceptually/ useful... but doesn't need to be carried through to the media types and RDF types.

I do think we should get rid of that "MUST" normative statement that @OR13 is referring to... I do think it's testable, but I question it's value. I mean, what's someone going to do -- insist that the unsecured credential they're transmitting is, in fact, a verifiable credential because we didn't normatively say what defines such a thing? I doubt folks will do that, but we will need to replace it with other (more focused) normative statements.

I do agree that we should be able to call, at a minimum, anything secured using any of the WG defined mechanisms a "Verifiable Credential/Presentation"... which includes a Data Integrity secured VCDM object as well as a JOSE/COSE secured VCDM object.

More specific thoughts below...

It also feels strange to me to say that a secured VC isn't a VC.

I agree, I wasn't trying to say we wouldn't call a "secured VC" a "VC".

I would go so far as to assert that it feels unnecessarily pedantic to insist on saying "VC secured by DI/JOSE/COSE/etc." vs just saying VC.

Agree.

I am honestly curious what harm may come if we say that those things defined by the VCDM are VCs (and they MUST be secured), and those VCDM-compliant things that are secured are still VCs.

I think that would be fine.

@OR13 wrote:

@msporny if proofs or security are optional the following is also true:

This WG has defined a data model for "credentials". This WG has defined multiple ways to "secure" the "credentials", that is to say to produce "verifiable credentials"...

Yep.

You seem to be disputing this MUST.... I suggest you raise a PR to correct the confusion, so we can review.

I'm not personally disputing the MUST... I think it's the more accurate statement. I'm trying to rationalize the decision the WG made to eliminate the distinction between "verifiable credential" and "credential". The spec /could/ be rewritten to just talk about "verifiable credentials", but I'm questioning the value of doing that. I'm also trying to not go back on a WG decision, but in this case, there seems to be an easier path as long as WG members are not going to insist that we define application/credential and the Credential RDF type again. If folks start doing that, then we're going to have to go back to this awkward process of trying to remove the distinction between a "credential" and a "verifiable credential".

As I said before JWT of typ vc+ld+jwt is just as much a verifiable credential as a JSON object of content type vc+ld+json returned by a web server... with at least one proof... regardless of "where" that proof is... could be detached, external, could be in http response headers, etc...

Agreed.

Assuming this normative sentence (which none of us seem to ever read the same way), is actually a requirement.

We should keep the sentence, but remove the MUST.

I would assert that ONLY vc+ld+jwt is consistently a verifiable credential, given that it always contains an external proof...

except when alg:none is used :)

and given that proof is optional in vc+ld+json....

Maybe we change the text to say something like: a verifiable credential MUST be secured using an external proof OR it MUST be secured using an internal proof, where the proof property is mandatory. IOW, we eliminate the possibility of vc+ld+json NOT having a proof (but only if it's not secured using an external proof mechanism).

I am willing to help correct this, by updating that normative MUST to say something like:

proof can be omitted and still the JSON is valid vc+ld+json, and 0 proofs (embedded or external) are required to produce a verifiable credential... (kinda rofl even reading this sentence).

No, let's not do that; feels unworkable.

... but perhaps it would be better to not touch this MUST, since it is currently the only normative statement in the core data model that tries to prevent alg: none from getting repeated all over again...

Yes, we should not open that up as an option.

.... absence of an embedded proof and absence of an external proof, tells you that a credential is unsecured... or in other words... that while the vc+ld+json is valid, it is not.... verifiable... and does not represent a verifiable credential, because it violates the normative MUST....

Agree in principle... perhaps we can break that MUST down into two statements:

1. It's a verifiable credential if it has a valid proof and thus can be encoded as application/vc+ld+json, OR
2. It's a verifiable credential if it is secured using an external proof, which can refer to the payload using a vc+ld+json media type.

... and if you don't meet one of those requirements, you're not dealing w/ a verifiable credential.

I'd argue the MUST is untestable... in its current form, so some update here is obviously needed... in order to get to CR.

We should get rid of the MUST in that particular sentence, and follow it up w/ something that's more easily testable (like a variation of what I mentioned above).

Perhaps the thing to focus on is a PR against that MUST statement that 1) keeps the distinction between "credential" and "verifiable credential", 2) removes the MUST statement in that sentence, and 3) adds two MUST statements that apply to VC-JOSE-COSE and VC-DATA-INTEGRITY (establishing that VCDM objects secured using those mechanisms are VCs).

Thoughts?

[OR13]

An alg non JWT is just like, data integrity proof with an RDF type that nobody understands how to verify... Or one that says "there is no security for this proof"... It's the same thing.

Using the same content type to refer to both secured and unsecured content, regardless of how the securing works, is repeating the alg none mistake.

Imo, the best option on the table, previously recommended by @TallTed is to say:

Verifiable Credentials don't always have proofs and even when they do, you don't know if you can verify them... But you can try.

It's a data model, trying to process it might fail... If it fails or you cant authenticate the data in some way that you trust, you have to treat the data as unsecured.

This is what the jwt spec says today, because... alg none exists.

The same is true of data integrity proofs (they exist).

The mistake is mixing media types for expressing secured representations with media types for expressing unsecured ones.

Which is another way of saying, the mistake is saying that credential and verifiable credential are the "same thing".

No matter what media type the core data model defines, protecting that media type with another one, solves the problem and removes the ambiguity.

If data integrity proofs, dont want to define

+ld+proof, or some suffix for communicating that JSON-LD is expected to be secured in some way the problem will persist.

The problem is a version of using the same word for 2 different things.

It's a problem for the core data model to solve, but regardless of the solution...

Adding +jwt to the media type will communicate that it is json being secured with JWS....

Data Integrity proofs seem to be trying to do something very similar...

Secure JSON-LD with an embedded JSON-LD object that can be used to represent anything.

I would define a structured suffix, or a media type parameter for data integrity, so you could tell the difference between JSON-LD and JSON-LD with data integrity, because otherwise people will treat all JSON-LD as having no data integrity, since that is the safest default.

As an aside, I might get rid of VerifiablePresentation (the rdf class), so you don't need a separate media type for something that is basically a subset of a Verifiable Credential... Keep the verifiableCredential graph container, make it a part of VerifiableCredential the rdf class (same with holder).

Then you have 1 media type, and a way to signal if it's supposed to be secured in some standard way or not.

Assuming we can't get consensus on any of what I said above, I will continue to advocate for securing json(-ld) with JOSE and COSE, because I believe the alternatives are not a security improvement over the existing capabilities we have for securing known content types.

[TallTed]

I haven't finished reading all of the above thread, but in response to @OR13's #123 (comment), I feel it's important to reiterate a point I've previously made, to wit:

A verifiable credential need not be successfully verifiable, which might mean a bad wrapper, or an internal proof failure, or no (internal or external) proof at all.

The current language of https://w3c.github.io/vc-data-model/#securing-verifiable-credentials —

At least one securing mechanism, and the details necessary to evaluate it, MUST be expressed for a credential or presentation to be a verifiable credential or verifiable presentation; that is, to be verifiable.

— particularly the closing phrase includes much from me... and I think that sentence, MUST be changed (and not only because we've dropped the definitions of [unverifiable] credential and [unverifiable] presentation, which we might want to restore, because there are other — i.e., non-W3C — forms of credential and presentation from which we should differentiate).

This is closer to the reality —

A verifiable credential or verifiable presentation MUST conform to this data model. Any expression of such a verifiable credential or verifiable presentation MUST be capable of being secured by at least one mechanism, and of carrying the details necessary to evaluate that securing mechanism, i.e., to verify that credential or presentation. Note that this evaluation need not be successful, and the details necessary to evaluate the securing mechanism need not be present nor accurate, for the credential or presentation to be considered a verifiable credential or verifiable presentation. In other words, verifiability does not imply successful nor complete verification.

[OR13]

Any expression of such a verifiable credential or verifiable presentation MUST be capable of being secured by at least one mechanism, and of carrying the details necessary to evaluate that securing mechanism.

Note that this evaluation need not be successful, and the details necessary to evaluate the securing mechanism need not be present nor accurate, for a verifiable credential or verifiable presentation to conform to the data model.

^ with some adjustment to remove the distinction between things we can't distinguish...

[TallTed]

The mistake is mixing media types for expressing secured representations with media types for expressing unsecured ones.

No. There is one base media type, which describes the format, which enables evaluation of the proof (whether internal or external).

alg=none should be evaluated by business logic to say that "the content of this structure is not tamper-evident, so all caution should be applied when using that content".

The same is true of any verification that fails, including any verification that finds no proof, neither internal nor external.

A password-secured ZIP archive has the same media type as any ZIP archive. The media type does not change when there's a password required to unzip the archive. The same SHOULD be true of [verifiable] {credentials|presentations}.

[TallTed]

^ with some adjustment to remove the distinction between things we can't distinguish...

I guess you're saying that we can't distinguish between verifiable credentials and verifiable presentations ... which may be true, in some senses.

In which case, we should stop talking about verifiable presentations, or perhaps define them as a specialization/subclass of verifiable credentials which are based on and/or enclose other verifiable credentials (as opposed to the verifiable credentials which are produced from whole cloth, i.e., with no enclosures nor provable derivations from other verifiable credentials, which will then need a different name, such that we have two subclasses which add up to one superclass).

[msporny]

we can't distinguish between verifiable credentials and verifiable presentations ... which may be true, in some senses.

I don't understand that statement... why can't we differentiate between them? They have media types and RDF types and you use BOTH in many cases... at least one in all cases. What am I missing?

[OR13]

That's not what I am saying.

We can't distinguish between credential and verifiable credential.

So we should not refer to them separately.

@TallTed suggested text that perpetuated this while attempting to address the normative MUST which is currently the only dividing line.

Once that line is removed, all credential are verifiable credential and there is no point is using 2 words for the same JSON object.

[OR13]

We can tell between verifiable credential and verifiable presentation, by looking at @type... Although I suppose it would be legal for an object to have both types.

[TallTed]

[@OR13] @TallTed suggested text that perpetuated this

I'm not sure what text I suggested, nor what I was perpetuating thereby. Linking to and/or actually quoting the relevant comments usually helps a LOT in reader comprehension.

[@OR13] We can tell between verifiable credential and verifiable presentation, by looking at @type

If @type is the only difference between a verifiable credential and a verifiable presentation, then why do we need two @types, rather than just paying attention to how they're being encountered/used/whatever?

If there is some other criterion that matters — some use to which a verifiable credential can be put to which a verifiable presentation cannot, or vice versa; or some attribute which a VC may have which a VP must not; etc. — then we should VERY clearly document that.

For your thought experiments: H₂O at –10°C can (typically) be typed as "ice"; at 50°C, it can be typed as "water"; at 110°C, it can (typically) be typed as "steam". All three of these "types" are really states, as they are all H₂O. Sometimes such distinctions matter; sometimes they do not.

[OR13]

@TallTed your comment that contains both credential and verifiable credential:

• Address Ambiguity Regarding Multiple Structured Suffixes #123 (comment)

My comment correcting that part of your suggested text:

• Address Ambiguity Regarding Multiple Structured Suffixes #123 (comment)

And just for clarity:

At least one securing mechanism, and the details necessary to evaluate it, MUST be expressed for a credential or presentation to be a verifiable credential or verifiable presentation; that is, to be verifiable.

^ this sentence is the problem:

1. it has a normative MUST
2. it asserts that proofs are required to distinguish "verifiable" things from un verifiable things.

[TallTed]

OK. I believe I was part of a group working on massaging that sentence, and do not deserve either full credit or full blame for its current wording.

Perhaps more accurately, based on current understanding —

A credential or presentation MUST conform to the data model described by this specification to be considered verifiable (i.e., to be a verifiable credential or verifiable presentation). Being verifiable does not imply success at that verification. At least one securing mechanism, and the details necessary to evaluate it, MUST be expressed for verification of a verifiable credential or verifiable presentation to succeed.

[OR13]

I think it's problematic to keep 4 terms when only 2 are required... And in order to address the MUST we will need to go from 4 to 2 somehow.

We don't need to define "credential" or "presentation" as being different than "verifiable credential" or "verifiable presentation".

I suggest the following approach to resolving this:

1. Update terminology to say there is no difference between the terms.
2. Remove as many sentences that imply there is a difference (including the MUST in the example above)

[msporny]

Update terminology to say there is no difference between the terms.

There is a conceptual difference, but making that conceptual difference concrete (by defining Credential and Presentation as RDF types) is not worth it... 'cause the point at which the WG cares about these things is when they become a VerifiableCredential and VerifiablePresentation.

For that reason, I like @TallTed's rewording and think that would address the issue... with the added caveat that we could remove "credential" and "presentation" from that normative definition... because the thing we care about in that normative definition is "verifiable credential" and "verifiable presentation".

In addition, we should say a "verifiable credential" and "verifiable presentation" MUST be secured using one of the securing mechanisms (which would make proof mandatory for DI-secured VCs... but would make it optional for externally-secured mechanisms).

All that said, a revision of @TallTed's suggestion:

A verifiable credential and a verifiable presentation MUST conform to the data model described by this specification to be considered verifiable. Being verifiable does not imply success at that verification. At least one securing mechanism, and the details necessary to evaluate it, MUST be expressed for verification of a verifiable credential or verifiable presentation to succeed.

[OR13]

At least one securing mechanism, and the details necessary to evaluate it, MUST be expressed for verification of a verifiable credential or verifiable presentation to succeed.

This part does seem better... It also lines up with @jandrieu 's request on another PR related to defining verification as separate from validation.

[OR13]

@TallTed @dlongley can you approve or request further changes?

[dlongley]

Not blocking this.

[TallTed]

Small tweaks. Modulo IETF action, I think this works.

[OR13]

heads up that this PR now also lines up with w3c/vc-specs-dir#14 (review)

[Sakurann]

why is it vc+ld+json+jwt and not vc+ld+jwt?

updated: I have read the discussion and think that vc+ld+json+jwt is a huge leap from today's one structured suffix world. vc+ld+jwt already stretches the line, and vc+ld+json+jwt would significantly hinder adoption in my mind....

[OR13]

@Sakurann I guess you missed the endless discussions of this at IETF and in this working group : )

Summarizing them here:

People in W3C (specifically @msporny and @TallTed , possibly others) like to have the entire core data model in the media type... so application/vc+ld+json becomes secured by appending +jwt or +sd-jwt or +cose.

The IETF list was asked, and didn't seem to agree with any use of multiple structured suffixes:

• https://mailarchive.ietf.org/arch/msg/media-types/NCBOqJG-53cXFHSjkdp8N5ffrbY/

@msporny sent this update:

• https://mailarchive.ietf.org/arch/msg/media-types/ZbsFgIK90kqbHBwWBBCW5woKJJs/

I don't think it matters how many + you have in your media type... Some software will process the last one, like +json... and some will process the entire thing as an opaque string.

The JSON-LD WG recently merged:

• Add structured suffix json-ld-syntax#415

Feel free to also comment on:

• Are expert reviewers expected to ensure media subtype semantics? ietf-wg-mediaman/suffixes#18
• Clarify that Structured Suffixes Registry is "Specification Required"? ietf-wg-mediaman/suffixes#16

TLDR, it does not matter what W3C requests registration of... it matters what the IETF process is and if you can distinguish media types.... IMO, the clearer we can make vc+ld+json+jwt as being related to the W3C JSON-LD core data model the better.

+ld+jwt is not a thing, and likely never will be... so it makes less sense to advocate for.

[OR13]

@Sakurann is Microsoft planning to implement vc+ld+json+jwt or vc+ld+jwt or only vc+sd-jwt ?

[OR13]

Potentially relevant to this work item, the case of JSON serialization of SD-JWT based W3C JSON-LD VCs... oauth-wg/oauth-selective-disclosure-jwt#327

[TallTed]

People in W3C (specifically @msporny and @TallTed , possibly others) like to have the entire core data model in the media type

Speaking for myself, I'd rather leave out everything about encapsulated data, and have media types only identify the type of any encapsulating resource. For instance, I'd rather have application/jwt which can be de-capsulated to reveal application/vc+ld+json, similar to how you can have application/gzip which can be gunzipped to reveal image/png (and there's no application/png+gzip), or application/zip which can be unzipped to reveal image/png (and there's no application/png+zip), or application/zip which can be unzipped to reveal image/png & text/plain & text/html & application/msword (and there's no sign of any of the encapsulated media types).

Others have advocated for building endless-string media types, always advertising whatever's been encapsulated or encoded, though this only works when the encapsulated/encoded is a single document (or at least, all encapsulated/encoded documents within a given "archive" are of a single media type).

[TallTed]

@OR13 @msporny --

My actual inclination as I described above appears (to me, anyway) to be aligned with Darrel Miller's expressed preference for "removal of the use of suffixes as a form of processing pipeline".

Structured suffixes should begin with the supertype (example/foo), and each additional + layer should narrow the subtype(s), from the largest on the right to the smallest on the left, which might be better understood through the zoological taxonomy --

zoological_taxonomy/Homo_sapiens_sapiens+Homo_sapiens+Homo+Hominini+Homininae+Hominidae+Simiiformes+Haplorhini+Primates+Mammalia+Chordata+Animalia+Eukaryota

Note: This is purely analog; it does not apply to anything on the Internet.

The idea is that the best (most specific) typing includes all of the above string. Supertypes are available by dropping each left-most segment including the + separator:

zoological_taxonomy/Homo_sapiens_sapiens+Homo_sapiens+Homo+Hominini+Homininae+Hominidae+Simiiformes+Haplorhini+Primates+Mammalia+Chordata+Animalia+Eukaryota
zoological_taxonomy/Homo_sapiens+Homo+Hominini+Homininae+Hominidae+Simiiformes+Haplorhini+Primates+Mammalia+Chordata+Animalia+Eukaryota
zoological_taxonomy/Homo+Hominini+Homininae+Hominidae+Simiiformes+Haplorhini+Primates+Mammalia+Chordata+Animalia+Eukaryota
zoological_taxonomy/Hominini+Homininae+Hominidae+Simiiformes+Haplorhini+Primates+Mammalia+Chordata+Animalia+Eukaryota
zoological_taxonomy/Homininae+Hominidae+Simiiformes+Haplorhini+Primates+Mammalia+Chordata+Animalia+Eukaryota
zoological_taxonomy/Hominidae+Simiiformes+Haplorhini+Primates+Mammalia+Chordata+Animalia+Eukaryota
zoological_taxonomy/Simiiformes+Haplorhini+Primates+Mammalia+Chordata+Animalia+Eukaryota
zoological_taxonomy/Haplorhini+Primates+Mammalia+Chordata+Animalia+Eukaryota
zoological_taxonomy/Primates+Mammalia+Chordata+Animalia+Eukaryota
zoological_taxonomy/Mammalia+Chordata+Animalia+Eukaryota
zoological_taxonomy/Chordata+Animalia+Eukaryota
zoological_taxonomy/Animalia+Eukaryota
zoological_taxonomy/Eukaryota

When we talk about media types of Internet documents, the typical expectation would be that applications are capable of dealing with the smallest subtype, but if they cannot (or their usage does not require that depth), then the application can fall back to whichever supertype they can deal with. The hope would be that applications would be able to handle very specific types, but not be required to handle any more specific type than actually required by their deployment.

Of course, deleting one or more subtypes in the middle (e.g., zoological_taxonomy/Mammalia+Eukaryota) would not render the remainder of the chain incorrect (the remaining subtype(s) would retain that relation to the remaining supertype(s)), but it SHOULD be disallowed, because consumers may not be able to deal with the smallest subtype, but able to deal with any of that subtype's supertypes. For the same reason, deleting right-side segments SHOULD be disallowed.

Obviously, the subtypes should stop when they reach the level of the document in question.

Maybe the above makes my preferences clearer?

[TallTed]

Forgive me for not responding on the IETF list; I've got too many subscriptions already.

Darrel Miller said:

My guess is that the only suffixes that browsers support is +json and +xml and I would be surprised if the browser vendors have plans to support any other suffixes.

Funnily enough, the browser vendors don't have to support any other suffixes. The magic of browser EXTENSIONs and ADD-ONs means that a more focused development community can address suffixes browsers don't support, as (for instance) the OpenLink Structured Data Sniffer — available for Google Chrome, Mozilla Firefox, Apple Safari, Microsoft Edge, Opera, and other Chromium-based browsers, through their typical add-on/extension "stores" — does today for a number of media type that are not well handled by any of these browsers.

[OR13]

I'm not sure I fully follow the recommendation.

It seems like perhaps you are arguing that the explicit typing stuff should only come in profiles of verifiable credentials, and we should not use any typ value in top level credentials... This saves us from ever needing to talk about +jwt or +sd-jwt in this spec, at the cost of potentially confusing JSON-LD and JSON in the future.

[TallTed]

It seems like perhaps you are arguing that the explicit typing stuff should only come in profiles of verifiable credentials, and we should not use any typ value in top level credentials...

I'm not sure what you mean by "profiles of verifiable credentials". I am saying that we should not put typ nor any other JWT (or other container) keys into the VC data layer (the payload of such container). Perhaps that's enough to answer the above?

This saves us from ever needing to talk about +jwt or +sd-jwt in this spec,

Yes! Wouldn't that be grand? (Well, we might need to talk about those things in this vc-jose-cose spec, but we definitely wouldn't in the primary VCDMv2 spec!)

at the cost of potentially confusing JSON-LD and JSON in the future.

I'm not sure how you think this confusion might happen. Provide more detail?

[alenhorvat]

@OR13 why is JOSE covering only securing with JWT?
JWS compact (+jose) and JWS JSON (+jose+json) are also being used. Should we open a new issue/PR?

See #132 (comment)

(this should not block the PR)

[andresuribe87]

For instance, I'd rather have application/jwt which can be de-capsulated to reveal application/vc+ld+json

Such de-capsulated object would not be a VCDMv2, as by itself, it is not cryptographically secured. @TallTed do you agree with that statement? If so, I think it causes confusion. If not, then I'd appreciate helping me update my mental model.

[OR13]

I am saying that we should not put typ nor any other JWT (or other container) keys into the VC data layer (the payload of such container).

The problem with this, is that some protocols assume specific payload keys... And without supporting them, the W3C JSON-LD Verifiable Credential data model can't be transported by that protocol, and people would need to invent an alternative, which would fragment the industry further and probably struggle to gain adoption.

Also because of how json works, you can't tell if someone really meant iss or just happened to use that key for some other purpose... Which means that similar to proof you can't ban it from the data model.

I think the best path forward is for the core data model to accept that securing mechanism extend it.

And that securing protocols might further extend it in the future.

[OR13]

@Sakurann its not clear what your feedback is.... I plan to merge over your change request, unless you express the change request in a form I can implement.

Can you say: "close this PR, I like the media types as is"... or "I accept the working group consensus on changing the requests to register media types".

[TallTed]

As with any cryptographically protected (i.e., encrypted) container, you can't see the data until you decrypt the container, and then it's no longer encrypted so it's no longer protected, but the data you get by decrypting the container is meant to be understood as verifiable, protected, etc.

I am boggled by the ongoing discussion that is apparently suggesting that verifiable credentials can only be used in their encrypted condition, where their encapsulated data is (or should be) unreadable.

[selfissued]

This aligns the media types in this spec with the ones in the VC Data Model. Therefore, I believe it makes sense to make this change.

[OR13]

I am boggled by the ongoing discussion that is apparently suggesting that verifiable credentials can only be used in their encrypted condition, where their encapsulated data is (or should be) unreadable.

Indeed, I am equally boggled by the use of the term "verifiable credential" to refer to things that have no actual security.

However, none of that is really relevant to this PR which is imply changing the media types requested for "secured" representations of "verifiable credentials" as opposed to the media types for "potentially secured representations", aka application/vc+ld+json.

PS no encryption is used... base64url encoding is not encryption.

[Sakurann]

I guess you missed the endless discussions of this at IETF and in this working group : )

I sure did... Thank a lot @OR13 for the summary. it make more sense now I guess. my thinking does not really change from what I said in a comment here, but since there seems to be an agreement on vc+ld+jwt+json I am not blocking this. (I won't explicitly approve, but will dismiss my request for changes).

per comment above

[OR13]

Merging, we will need to do a cleanup pass on the document asap... there are a few other places where this will need to be updated.