Closed OR13 closed 1 year ago
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.
@awoie can you help address key binding with verifiable presentations?
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?
I think as long as the core spec has data integrity proof protected VPs, people will expect sd-jwt protected VPs.
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)
@alenhorvat this PR is basically removing W3C recommending anything but +sd-jwt
based vc+ld+json
... do you plan to object?
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
@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.
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 ?
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.
@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
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
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:
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.
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.
@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:
application/vc+ld+json
and application/vp+ld+json
.application/vc+ld+json+sd-jwt
and application/vp+ld+json+sd-jwt
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.
That should not be a problem
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.
@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.
@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 )
Hi @Sakurann. I understand, and SD-JWT serialisation is perfectly fine for use cases that
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.
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 thatjson
subsets, this is invalid.The alternative would be something like
sd-jwt+vp+ld+json
wheresd-jwt
is further narrowing the processing model of the other three.
The issue was discussed in a meeting on 2023-09-14
Addresses https://github.com/w3c/vc-jose-cose/issues/141
Preview | Diff