Should application/cid define a profile= parameter?

[trwnh]

Taking these two issues together:

• Clarify that this specification is meant to be profiled #150
• Ensure that the application/cid media type is registered #153

If "this spec is meant to be profiled", and an application/cid media type was registered with the IANA, then why is that registration missing a profile= "optional parameter"? The use of an optional parameter to denote profile= is something that has been used in other IANA media types like application/ld+json and application/activity+json -- so given its absence in application/cid, one would have to assume another profiling mechanism is intended to be used?

• HTTP Link header with rel="profile"?
• Defining a new IANA media type that has a greater "media type precision" (as defined in DID 1.1 and VC 2.0)?

There's a lack of clarity on what was "meant" per #150, which I guess could have clarified more but didn't. Maybe adding a bit of info about what "profiling this spec" could/should look like would be useful?

Related: w3c/activitypub#574 is exploring what the use of CIDs would look like for ActivityPub actors. Naively, one might assume either adding inbox+outbox to the CID, or adopting terms from the cid/v1 context into an AS2 document. Maybe there are other answers (such as making the CID and actor be linked resources instead of the same thing), but I haven't gotten that far in thinking about the problem. I figured I should ask this leading question first.

[iherman]

This was discussed during the vcwg meeting on 20 May 2026.

View the transcript

w3c/cid#169

Brent: look at 169 to ensure Class IV is appropriate
… opened three weeks ago, would require an addition to the IANA registration for CID

Manu: I believe so, but forget what we registered. Suggestion is that we don't do this because multiple different profiles lead to non-interoperable implementations
… want to be specific about profiles, think we need the activity pub use case
… better thing would be for community to argue for changes into CID spec, need more info from them. Don't think profile leads to good interop

Patrick: just curious about idea that profiles hurt interop
… think profile can give clear pictures of what someone can align to, profiles being prescriptive about specification you want to implement. Don't see why they hurt, don't think they are ultimate solution
… I feel sometimes, some specs more than others there is a lot of optionality, optionality is good, but it can also spend a lot of time. Profile can give a path to a more direct implementation, not sure I totally agree that profiles are bad based on my limited experience

Manu: profiles are somewhat okay when what you explained ends up happening, but that is not always what happens. With CID spec, you can choose to punt JSON-LD to curb and add lots of features and make that your profile, then you have features that are a superset - you can just add whatever you want to
… typically that is not super great if it is not clear, yes you can do that, but inevitably it will make it so that your community is the only one that can implement
… adding profile allows you to do whatever you want, and sometimes people do things that completely break interop without any discussion with broader community, which is where interop failure comes in

Patrick: agree 100%, do not think profiles should extend capabilities, see them as extension of selected
… for me, this doesn't add anything, but agree if profiles want to use on own features that expand spec, can see why this would be dangerous path

<Zakim> manu, you wanted to note very little time to work on CID

Manu: +1 to that
… complete side note on spec, I'm one of the editors, have very little time to work on spec and it is lower priority, if there are other editors who would like to help out that would be great

Brent: 17 open issues in CID spec, 10 labeled Class II so we can address them.
… work to be done on this spec, need people to jump in
… look forward to meeting next week, then in Brusels

---