Remove JWT references (keep SD-JWT)

[OR13]

Addresses #141

---

Preview | Diff

[awoie]

lgtm

[Sakurann]

but i think it needs to be made clearer that key binding JWT must not be present for media type vc-...+sd-jwt and must be present for media type vp-...+sd-jwt

[OR13]

but i think it needs to be made clearer that key binding JWT must not be present for media type vc-...+sd-jwt and must be present for media type vp-...+sd-jwt

I don't know about this... its probably a separate issue to tackle.

In sd-jwt, making a presentation, does not require key binding, but if key binding is present... No "verifiable presentation" is even needed...

This makes vp+ld+json+sd-jwt kinda useless, except for when you want to disclose credentials or other holder claims selectively... with key binding.... that needs to be supported or recommended against, since its currently implied, underspecified, and confusing.

[OR13]

@awoie can you help address key binding with verifiable presentations?

[alenhorvat]

but i think it needs to be made clearer that key binding JWT must not be present for media type vc-...+sd-jwt and must be present for media type vp-...+sd-jwt

I don't know about this... its probably a separate issue to tackle.

In sd-jwt, making a presentation, does not require key binding, but if key binding is present... No "verifiable presentation" is even needed...

This makes vp+ld+json+sd-jwt kinda useless, except for when you want to disclose credentials or other holder claims selectively... with key binding.... that needs to be supported or recommended against, since its currently implied, underspecified, and confusing.

If SD-JWT is used with the serialisation presented in the specification, VP is unnecessary since an alternative representation of the VP exists (as introduced in the SD-JWT specs). However, the opposite is also true: when SD-JWT is used with VCs and VPs, novel SD-JWT serialisation is not needed. Everything can be covered with JOSE or DIP + VC/VP and _sd.

Edit: Hence vp+ld+json+sd-jwt should not exist.

IMO the two approaches can co-exist and should be described.
@OR13 @Sakurann, what do you think?

[OR13]

I think as long as the core spec has data integrity proof protected VPs, people will expect sd-jwt protected VPs.

[alenhorvat]

You can have SD-JWT-style selective disclosure and JOSE protection that works very nicely with VCs and VPs
https://code.europa.eu/ebsi/ecosystem/-/blob/EBIP-SD-JWT/drafts/draft-sd-jws.md
(without the serialisation part introduced in SD-JWT)

[OR13]

@alenhorvat this PR is basically removing W3C recommending anything but +sd-jwt based vc+ld+json... do you plan to object?

[alenhorvat]

Only now I see JOSE has been removed. This goes against JAdES and what we're using. (JAdES defines a profile for JOSE)

SD-JWT is fine, but I don't understand why JOSE has been removed. If JOSE can be re-added, it's fine, but now is a bit confusing: securing with JOSE -> SD-JWT

[OR13]

@alenhorvat thanks for the review.

I am opposed to registering several overlapping media types that do the same thing.

JOSE covers JWT, JWS, JWE and SD-JWT in my opinion.

VCs only need SD-JWT, and adding support for JWT would not work for JSON Serialized JAdES anyway.

You can use PGP to sign JSON-LD, that does not make a v2 conformant verifiable credential.

Similarly if you use something other than SD-JWT or COSE Sign1 to secure vc+ld+json (for example your link above), that will also not produce a verifiable credential.

[alenhorvat]

What we need is: https://code.europa.eu/ebsi/ecosystem/-/blob/EBIP-SD-JWT/drafts/draft-sd-jws.md
(ignore the pointer part, just the "encoding" and how information is transported from issuer -> holder, holder -> verifier)
The extra serialisation when using VCs and VPs is not required. Are SD-JWT authors open to this? It is not a breaking change since it can live along with the serialisation introduced in SD-JWT.

@Sakurann ?

[OR13]

You are asking for application/sdvc+json ... in order for this to be defined by W3C, someone will need to do a substantial amount of work.

I don't feel that work is necessary, (and I don't like your recommendation, as written)... you can just do this:

application/vc+ld+json+sd-jwt and change the compact serialization to flat and call it application/json.

If you plan to register application/sdvc+json as equivalent to the above example, that seems fine as well... and does not require coordination with W3C.

If your primary objection to sd-jwt is the ~ it seems that argument is best tackled on the OAuth list, W3C can't help... it can only register media types that secure JSON-LD payloads... alternate serializations for those media types are not our business.

On the other side of this argument, we could add more media types to the W3C spec, specifically for JSON serialization of "secured verifiable credentials" those media types would end in +json... so you might see:

application/vc+ld+json+sd-jwt+json

Current path is to not do that, and I hope its clear why.

[OR13]

@alenhorvat another note after reading your spec:

Even the @context may be hidden, although doing so might not confer any distinct benefits. As per VCDM2.0, the base media type can be modified with a documented transformation while preserving the qualities of the VC, provided it can be interpreted as originally intended. The VCDM2.0 can also be processed as JSON.Even the @context may be hidden, although doing so might not confer any distinct benefits. As per VCDM2.0, the base media type can be modified with a documented transformation while preserving the qualities of the VC, provided it can be interpreted as originally intended. The VCDM2.0 can also be processed as JSON.

This use case is already covered in the test suite.

See https://github.com/w3c/vc-jose-cose-test-suite/blob/main/testcases/secured-vc-jwt-sd/spec.yaml#L9

It seems the text above is also out of date regarding transformations. As of today, both the payload with disclosures and its verified form can be vc+ld+json and have terms defined in the v2 context, see:

https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L62

[alenhorvat]

Let's take one step back :) Sorry for the confusion

Simple question: if vc+ld+json is protected with JWS (compact or JSON serialised) (not JWT, not SD-JWT with ~ and key binding) what media type extension should be added? (no selective disclosure or anything, just VC secured with JWS without adding JWT claims to the payload)

https://www.rfc-editor.org/rfc/rfc7515
says: JOSE for compact serialised
JOSE+JSON for JSON serialised

[OR13]

Simple question: if vc+ld+json is protected with JWS (compact or JSON serialised) (not JWT, not SD-JWT with ~ and key binding) what media type extension should be added?

By definition, vc+ld+json as a "payload content type" aka "cty" value... is also a JWT!

If that envelope also has a protected header that says typ: ...+jwt then you know it's a specific type of JWT... and its following the JWT BCP.

The current proposal is for W3C to NOT call vc+ld+json secured with a JWS a "Secured form of W3C Verifiable Credential", so we are not giving it a media type name, and we are moving away from even acknowledging that it's possible.

For the sake of a clear argument, I would call what you are asking for:

application/vc+ld+json+jose and application/vc+ld+json+jose+json based on:

• https://www.iana.org/assignments/media-types/application/jose
• https://www.iana.org/assignments/media-types/application/jose+json

And to be clear, the W3C Verifiable Credentials working group does not recommend using them / doing what you are asking to do... If we wanted to recommend it, there would need to be a lot more spec text describing it in the document.

[alenhorvat]

JWT -> only compact serialised.

Essentially, you're saying securing VCs with JAdES is impossible? (https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.01.01_60/ts_11918201v010101p.pdf)

I don't understand what's the issue with +jose, +jose+json

I'm happy to contribute and extend the specs to cover it if that's an issue.

[OR13]

@alenhorvat

Essentially, you're saying securing VCs with JAdES is impossible? (https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.01.01_60/ts_11918201v010101p.pdf)

I'm saying, as of this comment, W3C VCWG is not saying anything about JAdES, and is only recommending SD-JWT and COSE Sign 1.

That means JAdES is not a way to represent W3C JSON-LD based verifiable credentials.

I'm happy to contribute and extend the specs to cover it if that's an issue.

Lets be clear on what you would be signing up for:

1. documenting all the JAdES compatible media types, and explaining how each applies to application/vc+ld+json and application/vp+ld+json.
2. creating new media types for "JAdES secured W3C JSON-LD based Verifiable Credentials", similar to SD-JWT secured W3C Verifiable Credentials, aka application/vc+ld+json+sd-jwt and application/vp+ld+json+sd-jwt
3. addressing any key discovery / issuer or holder meta data issues associated with JAdES header parameters such as kid, cnf, iss and sub.

If you feel its possible to address these issues before this work item goes into CR, then I think its reasonable to hold you accountable to getting that work done, but it looks like a lot of work, and I don't have high confidence that it is "worth it"... cc @Sakurann @brentzundel Maybe a topic for you to address in person, its a bit late to be considering this kind of scope, but if the working group needs to run a fire drill for JAdES you will need to clear the way soon, or its not going to be possible to address.

[alenhorvat]

That should not be a problem

1. JAdES is +jose or +jose+json and defines 4 profiles
2. This is something I'd like to discuss - we can open a separate issue wrt typing (not sure where's the best place to discuss the media type vs typ vs cty)
3. ETSI standard covers this for x509. We can explain the "mapping" if required, and provide examples, ...; We also have a profile for DID-based discovery/resolution (ETSI JAdES-conformant); it's a matter of transposing the documentation into a format suitable for this specification

We can create a separate document addressing all the points, present it to the WG and see how it evolves.

WDYT?

wrt "worth it" -> CAdES, PAdES, and XAdES are three cross-border recognised signatures (across the whole EU) with the same legal recognition as a handwritten signature. JAdES is a JWS/JSON variant of *AdES.

[OR13]

@alenhorvat Lets start by moving the discussion to a dedicated issue.

If we are going to tackle JAdES in a W3C TR... we are really far behind on getting that to a "safe place", and some emergency powers might be required to get it done in time.

If you have a chance to sync with chairs, I also suggest you do that.

[Sakurann]

@alenhorvat, we have been discussing over a period of time, but SD-JWT as-is does support JSON serialization. maybe the design is not exactly what you have preferred, and that is why editors have been engaging separately to explain why certain design choices have been made. some of the topics raised should be fundamentally be addressed in sd-jwt spec, so that bottomline +sd-jwt should be sufficient to cover what I think you are trying to cover with +jose. (cc @danielfett @bc-pi )

[alenhorvat]

Hi @Sakurann. I understand, and SD-JWT serialisation is perfectly fine for use cases that

• don't use VPs
• natural Person VCs that do require selective disclosure
• don't need double signed VC by the issuer (VC and VC+disclosures signed explicitly)

However, we have a lot of Legal Entity VCs that don't require selective disclosure and UC where natural person VCs don't require SD, and we need to protect them with plain JWS (JAdES). When doing SD-JWT and using VPs, the serialisations introduced in SD-JWT are not required.

There are two options
a) as discussed with @OR13 we define a separate section about protecting with JWS/JAdES; no change to SD-JWT
b) SD-JWT specs are extended (no breaking change to the existing design) to cover the cases described above (so: no ~ in the limit when there are no disclosures, explaining the key binding when VPs are used, explaining how to package the disclosures when VPs are used) - you rejected the proposal once already.

If you're open to a discussion, that would be great.

Note that option a) is not an issue for us to document if b) is out of SD-JWT scope.

[BigBlueHat]

Retracting based on discussions at TPAC. I'd misunderstood the sd-jwt base media types approach to processing. Leaving the rest for posterity...

---

vp+ld+json+sd-jwt

This seems backwards. Media type definitions are hierarchical, not combinatorial, so unless there's a unique sd-jwt processing model that json subsets, this is invalid.

The alternative would be something like sd-jwt+vp+ld+json where sd-jwt is further narrowing the processing model of the other three.

[iherman]

The issue was discussed in a meeting on 2023-09-14

• no resolutions were taken

View the transcript

6.2. Remove JWT references (keep SD-JWT) (pr vc-jose-cose#149)

See github pull request vc-jose-cose#149.

Michael Jones: given that in ietf, there is work on sd-jwt that both allow an option with and without selective disclosure. editors felt that just using sd-jwt covers only jwts.

Manu Sporny: this feels like a significant change in direction.

Manu Sporny: using JWTs to secure has been a thing for a while. but now it looks like now using sd-jwts will be a must if one is trying to secure VCs using JOSE stack.
� then the whole point of a stack does not match the purpose.
� please clarify if the point is not to support regular JWTs and how using SD-JWT enables CWT or CBOR based securing mechanisms.

Brent Zundel: i had a similar thoughts. comments in this PR seemed that SD-JWT is a superset of a JWT so it is possible to have a JWT with or without SD components.

Dave Longley: +1 to hear more about the state of SD-JWT in the standards process.

Dave Longley: and where it is relative to something like where BBS is.

Brent Zundel: my concern with this concern is similar to the concerns for BBS - whether sd-jwt is in a state where we can refer to it normatively.

Michael Jones: what we a doing is changing a media type, there is no normative reference to sd-jwt ietf draft.

Manu Sporny: that does not answer the question. in order to use sd-jwt, you have to put normative changes to it.
� we need to understand where in the standardization process sd-jwt is.
� understand that editors want to move away from jwts and focus on sd-jwt.

Ted Thibodeau Jr.: There's a whole lot more than media types changed in https://github.com/w3c/vc-jose-cose/pull/149/files.

Manu Sporny: several implementers using vc-jwt as defined in vcdm 1.1 who might be surprised with this change.

Brent Zundel: +1 with JWTs still being in scope according to my understanding.

Michael Jones: disagree with the characterization that we are taking away the option to use JWTs that is in scope - we are only removing largely duplicative option, since one is a superset - trying to reduce the number of media types.

Dave Longley: notes the PR is called "Remove JWT references (keep SD-JWT)" ... it would be good to change that if that's not what's happening.

Ted Thibodeau Jr.: to be clear there is more text change than media types.

Oliver Terbu: agree with what was said: sd-jwt is superset of jwt. agree with using sd-jwt, the rest is redundant.

Sebastian Crane: understand that it is subset. why it is called sd-jwt?

Manu Sporny: this PR removes a media type for regular JWTs - understand that sd-jwt is a superset. it feels like we are removing support for JWTs.
� you can take a subclass of jwts and point to jwt processor, but that is not the case with sd-jwt.
� we are telling people that we are telling people to support sd-jwts.

Brent Zundel: respond to sebastian - sd-jwt is considered a jwt because it adds functionality to jwts, but does not remove.
� my understanding is that i can take a normal library, generate a JWT, append ~ and call it an sd-jwt.
� so using regular jwt libraries to do sd-jwts is possible. that was all chair hat off.

Dave Longley: regular JWT lib gets a JWT with ~ at the end ... not a major problem but it does sound like we need a normative reference to SD-JWT?

Oliver Terbu: agree with brent. can use regular jwt libraries. one need to upgrade to v2.0 from v.1.1 anyway. no reason to maintain vc-jwt as in 1.1.

Sebastian Crane: question to mike. any change to cbor support?

Michael Jones: no change to cbor support.

Kristina Yasuda: I think the direction is correct. We experimented a lot with the best way to secure a payload that enables switching selective disclosure on and off.
� we first tried JWT and SD-JWT switching off. But having experimented and implemented, they are not different, it is just appending a ~ to a regular JWT. Those who are currently using JWT and want to contuinue and those who want to use SD with JWT both are there (chaIR HAT OFF).
� however PR could explain more, happy to help with that.

Benjamin Young: question around media type declarations. is sd-jwt a superset of json processing?
� and that is expressed in this PR?

Manu Sporny: this have to do with multiple suffixes thing - current formulation is a correct formulation based on what is happening in the ietf.
� multisuffixes WG in IETF.
� I did not say it is impossible to use. it is different enough and it is dangerous to say sd-jwt is a jwt.
� fine if the PR made it very clear that you should be using a library sd-jwt that can process media type.
� suggesting that jwt library can be used as-is is not ok.
� not clear if the group wants to abandon jwts and focus on sd-jwt.

Dave Longley: +1 to manu, fine to do SD-JWT, but normative reference and stability required.

Manu Sporny: need to add normative reference to sd-jwt.

Kristina Yasuda: I don't disagree.

Manu Sporny: +1 to kristina -- add a validation/processing section that tell people they should use SD-JWT libraries to do the processing.

Kristina Yasuda: all the SD-JWT implementations I've seen use JWT libraries, but adding something to make it clear would be good. I don't think we're abandoning JWTs. Correct framing is moving on we're enabling using JWT with or without selective disclosure.

Kristina Yasuda: not sure the validate section should talk about libraries, but yes.

Sebastian Crane: concerned about adding sd-jwt.
� agree with manu's concerns and proposed path forward.

Paul Dietrich: you can create an sd-jwt to add a ~. easy for the issuer. how does the verifier know when it is the same media type whether there is SD or not?

Kristina Yasuda: You would need to look at the number of tildes. The processing section could clarify. If a verifier gets something with no selective disclosure there one tilde at the end. with SD there are more tildes at the end. The verifier would need that logic to determine.

Paul Dietrich: a way to ask something without a SD?

Kristina Yasuda: depends on the protocol used to request a credential. presentation exchange would allow to request a thing without SD wihtout using media types.

Michael Jones: given we're trying to move toward CR. There's 6 approvals and minor call for suggested changes. Can we raise an issue for the remaining concerns?
� can we merge this PR and open issue on the path forward we agreed upon.

Benjamin Young: sd-jwt has to be a normative reference.

Manu Sporny: raising another issue that will have to be tagged pre-CR.
� would be nice to fix in this PR.

Brent Zundel: noting that mikeJ's way forward is not manu's favorite, we can do merge that PR.