Request profile parameter from application/vc

[OR13]

For example application/ld+json already supports profile:

application/ld+json; profile="https://www.w3.org/ns/credentials"

application/vc+... could similarly support profile:

application/vc+ld+json; profile="https://market-vertical.example/ns/credentials"

See the related thread from the CG list:

• https://lists.w3.org/Archives/Public/public-credentials/2023Nov/0080.html

So, if you're doing a VCDM v2.0 VC secured using Anoncreds, your VC
will end up having this as the context (because DataIntegrityProof is
included by default in VCDM v2.0):

"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://market-vertical.example/contexts/v1"
]

and if you're doing a VCDM v1.1 VC secured using Anoncreds, your VC
ends up w/ this context (because DataIntegrityProof IS NOT included by
default in VCDM v1.0 or v1.1):

"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/security/data-integrity/v2",
"https://market-vertical.example/contexts/v1"
]

and if Anoncreds needs to define new properties (which I'd very
strongly advise against), your VC ends up w/ this context:

"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://anoncreds.example/contexts/v1",
"https://market-vertical.example/contexts/v1"
]

[OR13]

We have a related issue open regarding vc-jose-cose at w3c/vc-jose-cose#184

I suppose there are also considerations regarding profile and data integrity, for example:

application/ld+json; profile="https://w3id.org/security/data-integrity"

^ The above would signal the use of data integrity as defined by https://github.com/perma-id/w3id.org which could be the same as or different from:

application/ld+json; profile="https://www.w3.org/ns/security/data-integrity"

The security namespace (https://www.w3.org/ns/security) only appears in data integrity afaik...

See https://w3c.github.io/vc-data-integrity/#example-json-web-key-encoding-of-an-ed25519-public-key

https://www.w3.org/ns/security does not appear in the core data model specification.

[OR13]

I raised w3c/vc-jose-cose#186 which removes part of this issue from vc-jose-cose, but it remains an issue in the core data model.

For example, a JOSE or COSE credential could have the following typ values now:

"typ":  "application/jwt",
...
"typ":  "application/sd-jwt",
...
"typ":  "application/cose",
...
"typ":  "application/jwt; profile=42", // assuming profile was registered.
...
"typ":  "application/cwt; profile=42", // assuming profile was registered.

By not mandating a specific value for typ we protect against ossification, which was raised as a concern here:

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

We have the same issue with cty values / the media types requested to be registered in the core data model.

"cty":  "application/vc+ld+json",
...
"cty":  "application/vc+ld+json; profile=v2?", // assuming profile was registered.
...
"cty":  "application/vc2+ld+json; profile=v2?", // assuming profile was NOT registered.
...

Does application/vc+ld+json work with v1 or only v2 ?

See the related registration request from activity streams:

https://www.w3.org/TR/activitystreams-core/#media-type

They opted to use just +json and a profile parameter... maybe we should do the same?

It seems reasonable to assume that people will register new subtypes, in the case that application/vc+ does not register profile... because there won't be any other way to signal a version upgrade.

See also: w3c/vc-jose-cose#186 (comment)

[OR13]

I suggest:

1. marking the registrations at risk
2. copy something like the text we have in did core
3. add text providing guidance on parameters correct use of parameters
4. add warnings about parameters

[OR13]

recently raised (related) :

• Do VCs still need Media Types with Multiple Suffixes? #1364

[iherman]

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

• no resolutions were taken

View the transcript

1.4. Request profile parameter from application/vc (issue vc-data-model#1363)

See github issue vc-data-model#1363.

Brent Zundel: The current path we are on relies on media types with multiple suffixes.
… The spec for multiple suffixes in IETF has been more contentious than anticipated.
… And possibly a whole lot more work than anticipated.
… This issue is another path to sidestep this.

Orie Steele: This issue can be used with or without multiple suffixes.
… Our current registrations require multiple suffixes, even though this isn't possible at present.
… Even for application/vc the subtype can contain media type parameters.
… Those parameters can express characteristics of the media type.
… Specifying the text type is a common usage.
… This tracks the intended use of the profile parameter.
… We should provide guidance on the use of profile.
… We could say not to use it.
… We could say to use it in the same way as ld+json.

Brent Zundel: Thank you for clarifying the relationship between the parameters.
… We can register media types with multiple suffixes.
… The current interpretation of a+b+c is that a is the prefix and b+c is the suffix.

Orie Steele: we can request registrations that rely on multiple suffixes, but they cannot be registered, until their interpretation is clear... it is a mistake to request registrations that we know cannot be approved.

Ted Thibodeau Jr.: The first thing after the slash isn't what matters.
… The subtype is what's after the last + sign.
… There are multiple layers of subtyping.
… I don't know why the IETF did this.

Orie Steele: if you have questions regarding media types, you can ask the media type list. see https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes/.

Ted Thibodeau Jr.: You process as many of the subtypes that you understand.
… This is complex and esoteric.

Orie Steele: +1 TallTed, its complicated : (.

Ted Thibodeau Jr.: The problem with multiple + signs is that the interpretation is undefined.
… There may be many more drafts.
… We can specify what our media types mean but those will only apply to people who understand our spec.
… It's to let people who don't understand what's to the left of the +s to still work with what's to the right of the +s.

Orie Steele: here is the repo: https://github.com/ietf-wg-mediaman/suffixes ... TallTed, eager to see your PR : ).

Manu Sporny: I am the editor of that spec.
… There is only one remaining issue.
… It's about whether to register all the things in between.

Dave Longley: for "application/vc+ld+json" processing is: "application", then "json", then "ld+json", then "vc+ld+json" ... another way to understand this subclass processing is: "application/square+rectangle+shape" ... you can understand any "application" content, then, if you want, more specifically any "shape", ... then any "rectangle" ... "square".

Manu Sporny: The chair of the WG wants to take it to last call.
… I don't think the multiple structured suffixes draft is in a place that it's not going to be ratified soon.
… Ted is right that we can just specify what our media types mean.
… We don't need to change anything about the media types used in the spec.
… The profile problem is problemantic.
… Many people don't prrocess it.

Orie Steele: My recommendation would be to not depend on multiple suffixes, we raised a PR to remove the dependency from vc-jose-cose ... w3c/vc-jose-cose#186.

Orie Steele: related registration for https://www.iana.org/assignments/media-types/application/ld+json.

Orie Steele: related specification Manu mentioned: https://www.w3.org/TR/activitystreams-core/#media-type.

Manu Sporny: You can have multiple different IETF registrations stomp over it.
… I realize we used it in JSON-LD. I wish we hadn't.
… We can tell people not to use it.
… What we've learned is that people don't implement it correctly.
… It's often destroyed or mangled as it goes through HTTP servers.
… We can only pick one filename suffix.
… We can't use profile to do that.

Orie Steele: feels like implementing profile correctly, is easier than using multiple suffixes consistently.

Dmitri Zagidulin: @orie - agree.

Ted Thibodeau Jr.: sighs people who don't conform to specs (e.g., by misconfiguring servers or otherwise breaking the profile option) should not be justification for not conforming to specs!

Manu Sporny: It's not easier to implement profile correctly, Orie. :) -- We have multiple decades of experience now that people don't implement it correctly.

Dave Longley: as long as multiple suffixes follows the rule that each subtype fits within the same wider syntax, things are kept clean (and correct) ... i think trouble has come from people thinking it's for enveloping, when it isn't.

Manu Sporny: ^ yes, that.

Manu Sporny: (to what dlongley said).

Dmitri Zagidulin: I want to agree with Orie that hierarchical multiple suffixes is way more trouble than it's worth.
… I don't think there's any need for hierarchical multiple suffixes.

Orie Steele: +1 ivan.

Dmitri Zagidulin: +1 to at risk.

Ivan Herman: If we want to keep multiple suffixes, we should put the whole concept as being at risk in the document.
… Put it as at risk.
… We can see what happens at the IETF.
… If it goes through at IETF, we can remove the at risk.
… Otherwise we can reconsider.
… We have to defend ourselves.

Brent Zundel: We're relying on multiple suffixes but not normatively pointing to them.

Manu Sporny: Note that JSON-LD has gone through multiple RECs w/ this in there: https://w3c.github.io/json-ld-syntax/#structured-extension-ld-json.

Ivan Herman: On the other hand, we are supposed to register media types we use during CR and we can't do it now.
… We can't ignore this.
… That's why we have to mark it as at-risk.

Orie Steele: I spoke to our W3C liaison at the IETF - Martin.
… It might be fine to go into CR that way.
… To become a recommendation, we have to finish the IETF work.
… It's OK to go into CR with the references are they are.
… If we have to correct this, it would be good to be able to do this without going through CR.
… If marking it as at-risk helps, let's do that.
… I don't know how the DID spec got to Rec with multiple suffixes.
… If this isn't resolved before REC, I will formally object.

Orie Steele: thats not true manu.

Orie Steele: I added the +ld+json structured suffix.

Manu Sporny: The DID and JSON-LD specs have gone through REC with multiple structured suffixes.
… You can treat it as an opaque thing.
… We can change it to application/vc if we need to.
… But that's doing the wrong thing.
… We should fix the IETF's broken suffixes.
… We should stop routing around this damage at the IETF.

See github pull request json-ld-syntax#415.

Brent Zundel: https://www.w3.org/TR/did-core/#application-did-ld-json.

Orie Steele: seems like the W3C is responsible for the broken behavior, and I agree that it needs to be fixed.

Orie Steele: I am trying to fix it FWIW.

Brent Zundel: The DID spec said that it will be registered as soon as the IETF spec is done.

Ivan Herman: The only thing I don't want is to go there and not even mention the problem.
… If we include a note like we did in the DID spec, that may be enough.

Brent Zundel: What are the steps forward for the profile parameter issue?
… We could prohibit their use or say how to use them.

Manu Sporny: We tell people how to use profile parameters correctly.
… Expect people to break this and it not to work correctly across the ecosystem.
… We should warn them that it has never worked out well when people rely on the profile parameter.

Ivan Herman: +1 to manu's direction.

Brent Zundel: We don't need to include doomsaying.
… We would need someone willing to be assigned to the issue.
… If you feel strongly that doing nothing is the right approach, then please volunteer to be assigned.
… If noone is assigned, then by default, we will be doing nothing about this.

Orie Steele: the media types impact the "verification algorithm".

Ivan Herman: All these options we are talking about are editorial?

Orie Steele: are they still editorial?

Brent Zundel: The media types affect the verification algorithm.
… We don't have anyone willing to be assigned.

Orie Steele: the reason I am not volunteering is that we are removing the dependency from vc-jose-cose.

[selfissued]

As I wrote at https://mailarchive.ietf.org/arch/msg/oauth/vDitVdgDfL4ZXzPdvquoCj_fYbY/, I would prefer that we update our registrations to prohibit the use of media type parameters, to increase the likelihood of interoperability.

[msporny]

I agree with @selfissued, and have elaborated on why, here.

[OR13]

I prefer the validation / verification algorithm to explicitly prohibit parameters before this is closed.

#1338 (comment)

[msporny]

PR #1382 has been raised to address this issue. This issue will be closed once PR #1382 has been merged.

[iherman]

The issue was discussed in a meeting on 2023-12-13

• no resolutions were taken

View the transcript

2.9. Request profile parameter from application/vc (issue vc-data-model#1363)

See github issue vc-data-model#1363.

Brent Zundel: request profile parameter for application/vc+ld+json.

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

Orie Steele: see this recent cg draft using profile: https://www.w3.org/community/reports/json-ld/CG-FINAL-yaml-ld-20231206/.

Brent Zundel: not sure about the course this is taking.

Orie Steele: I think that PR is on a good track, Manu's attempting to address ambiguity, forbid profile parameter. From a design perspective, bad to say extensibility for profile is internal to media type. For awareness of the group, JSON-LD CG just published for YAML-LD that also registers profile parameter. I think it's a best practice to inherit the profile parameter the way all the other media types tend to support it and then say, when it's present, it has to be interpreted in some way and if you don't have a need for it, don't use it. That would be my recommendation. This will impact registration of media types, since we're first through the door on multiple suffixes, it would be wise of us to be explicit about profile parameter.

Ted Thibodeau Jr.: I am very confused by orie's comments.
… the PR is titled forbid use of media type parameters.
… I take issue with forbidding parameters, media type parameters should not be forbidden'.
… some content still needs to be changed.

Manu Sporny: seems you are missing context from the special topic, there was pushback forbidding media type parameters.
… you seem to want to address profile, not forbid media type parameters.
… we had too many objections to forbidding the profile parameter.
… we tried to resolve to say nothing.
… i believe orie wanted us to provide guidance on the profile parameter.
… in case the media type parameter is inherited from the suffix.

Dave Longley: IMO, it still seems clear that we don't know what we want to say and so we should say nothing at all.

Ivan Herman: +1 to dlongley.

Dave Longley: to me, it seems like we don't as a group know what to say here, so we should say nothing.

Orie Steele: I am fine closing all these.

Brent Zundel: if nobody is opposed, lets do that.

Manu Sporny: we have to remember to account for media type parameters.
… in the verification algorithm'.
… not clear how to verify if parameters are present.
… good to close it, but we will need to update the verification algorithm.

Brent Zundel: we have a path forward.

[msporny]

PR #1382 has been merged, closing.