Requesting content type for credential (without proof).

[OR13]

Update

I made 3 related proposals to the list:

• https://lists.w3.org/Archives/Public/public-vc-wg/2022Dec/0032.html
• https://lists.w3.org/Archives/Public/public-vc-wg/2022Dec/0011.html
• https://lists.w3.org/Archives/Public/public-vc-wg/2022Nov/0034.html

All 3 proposals request a JSON media type application/credential+json, based on the convention established by activity streams.

Previous Description

This would allow for a W3C Credential to become a SCITT claim (terminology differs).

This would also allow for COSE Sign1 to be used.

Essentially a SCITT Claim could become a Verifiable Credential, when used with COSE Sign1 with a header that looks like this:

{
  iss: did:example:123,
  kid: #0,
  cty: application/w3c-credential+json <-- this is what I need
}

{ w3c-credential json as "payload" }

signature

Note that this would not be a "vc-cwt"... and yet, its still very useful...

We might propose a vc-cwt with a mapping similar to vc-jwt for consistency, but that would not be a solution to this use case.

[mprorock]

Getting a content type like this would be awesome and very helpful in SCITT and elsewhere.

Perhaps the following as a starting place?

application/verifiable-credential+json
application/verifiable-credential+json-ld
application/verifiable-credential+jwt

[OR13]

@mprorock following the convention from DID WG, we would have the following:

application/verifiable-credential+json
application/verifiable-credential+ld+json

Both would be examples of "verifiable credentials with external proofs" similar to how VC-JWT is a "VC with external proof".

[mprorock]

@mprorock following the convention from DID WG, we would have the following:

application/verifiable-credential+json
application/verifiable-credential+ld+json

Both would be examples of "verifiable credentials with external proofs" similar to how VC-JWT is a "VC with external proof".

That make total sense and works for me

[letmaik]

+1 though it seems like the media type would be for the credential itself, and the complete structure with signing envelope is the verifiable credential. I think it's important to distinguish this.

[OR13]

@letmaik yes, thats what I proposed originally, but due to this language in the existing TR, that concept may be confusing to readers:

https://www.w3.org/TR/vc-data-model/#proofs-signatures

TLDR, the WG has defined "verifiable credentials" in a way that conflates them with "credentials" when an "external proof" is applied.

[OR13]

This has been superseded by several other conversations:

• Securing the VC Data Model with JOSE #971
• Enable CBOR Representation(s) of Verifiable Credentials #985

[brentzundel]

This has been superseded by several other conversations:

• Securing the VC Data Model with JOSE #971
• Enable CBOR Representation(s) of Verifiable Credentials #985

should this Issue be closed and the discussion continued in those issues?

[OR13]

Related #421

[Sakurann]

To elaborate a little bit on the comment I made on the PR.

I think it would be appropriate to define cty JOSE headers application/credential+json and application/credential+ld+json (maybe also application/credential+cbor but I am still wrapping my head around why sign CBOR body with JWS, which should be a separate thread). There are clearly different types of encoding of the JWT body (to borrow terminology from Syntaxes section), which are all being secured using JWS.

cty JWT claim would be appropriate, since by definition it is meant to be used to declare the media type of the secured content (the payload).

This is for a separate issue/PR, but typ JOSE header parameter verifiable-credential+jws should probably also be defined to declare the media type of this complete JWS.

[OR13]

People use COSE to sign JSON... usually because they can't get people to stop using JSON... relevant:

https://github.com/microsoft/scitt-ccf-ledger/pull/67/files

Compatible proposal for the VCWG: https://lists.w3.org/Archives/Public/public-vc-wg/2022Dec/0011.html

I agree with your comment about typ... that is where we should see verifiable-credential+jws.

[msporny]

Here's a proposal for a unified philosophy for doing media type processing for Verifiable Credentials:

1. There will be at least two media types, one for unsecured credentials and another for secured credentials.
2. The unsecured credential media type will be application/credential+json, which will be equivalent to application/ld+json with a profile set to https://www.w3.org/ns/credentials.
3. The secured credential media type will be application/verifiable-credential+json, which will be equivalent to application/ld+json with a profile set to https://www.w3.org/ns/credentials.

Once we define these media types, we'll have to talk about what happens when things go wrong, such as:

1. What happens when the client just requests application/json, or application/ld+json (with or without a profile set) for a known good application/credential+json resource?
2. What happens when the client requests application/credential+json but the server responds with application/json?
3. Same questions above, but for application/ld+json instead of application/json?
4. What is the content type for a data integrity protected application/credential+json? A JWT-protected one? A JWS-protected one? A CWT-protected one?

I suggest the answers to the questions above are:

1. Return the same content as for application/credential+json.
2. Use rules (yet to be written) to do deterministic content sniffing on the payload (look for @context with specific values (for v1 and v2) in the first array element).
3. Same as answer to 2 above.
4. application/verifiable-credential+json, application/verifiable-credential+jwt, application/verifiable-credential+jws, and application/verifiable-credential+cwt, respectively.

Thoughts?

[dlongley]

Also, if people want to publish VCs in web pages, which media type should they use? Is it going to make things more challenging for this use case if we have extra media types that mean the same thing? People publish structured data using application/ld+json today and it's consumed by major search engines.

[OR13]

I raised this issue, and I believe it can be closed now, due to #1000

[mprorock]

agree

[iherman]

The issue was discussed in a meeting on 2023-01-17

• no resolutions were taken

View the transcript

2. Requesting content type for credential (pr vc-data-model#978)

See github issue vc-data-model#978.

Brent Zundel: Let's look at #978 first.
… I raised this issue. I believe this can be closed now that PR #1000 has been merge..
… You can indicate that since PR #1000 was merged, this can be closed.

Orie Steele: The issue is now closed.

Michael Prorock: depends on length of time open, and sufficient working group input in my mind, which was definitely the case for #1000.

Brent Zundel: Tony asked in the Zoom chat if it wouldn't have been more appropriate to merge during a main call.
… The PR already met criteria for being merged. We merge things not only during calls..

Manu Sporny: Our work mode is that if it's been open for 7 days and there are no objections, it's fine to merge things..