Closed mprorock closed 1 year ago
This will let us focus very clearly on securing the core data model section and have something very usable. This is obviously not to say we don't want to secure JSON with registered claims, but that we can do that elsewhere or revisit later
The issue was discussed in a meeting on 2023-05-24
This change might also necessitate some removal in A.1 and A.3, as well as A4.1. I think these sections would be confusing otherwise.
@mprorock can you apply @paulfdietrich comment? And remove those appendix sections?
@mprorock can you apply @paulfdietrich comment? And remove those appendix sections?
done, thanks for the careful read @paulfdietrich
It should be the other way around. There is sufficient market interest in having a vanilla JSON payload in VC-JWT.
@Sakurann we are not chartered to secure arbitrary JSON, we are chartered to secure "vc+ld+json".
@iherman please confirm the charter details, if I am incorrect, we have wasted a tremendous amount of time, over objections that are unfounded.
@OR13 our scope is sufficiently broad enough to support specifying how to secure arbitrary JSON using VC-JWT (in addition to how to secure vc+ld+json), but that isn't the same as having consensus to do so.
From my perspective there is no consensus to define a normative mapping, or to retain optional mappings with no normative teeth... this is the same as admitting there is no consensus to secure JSON, or any other content types in this working group.
@brentzundel @Sakurann please establish consensus on this topic, editors can't advance the document to horizontal review without it.
Conflict free version is here: https://github.com/w3c/vc-jwt/pull/102/files
It should be the other way around. There is sufficient market interest in having a vanilla JSON payload in VC-JWT.
@Sakurann we are not chartered to secure arbitrary JSON, we are chartered to secure "vc+ld+json".
@iherman please confirm the charter details, if I am incorrect, we have wasted a tremendous amount of time, over objections that are unfounded.
I do not see any charter issues. The charter does not mention media types, only VC-s in general.
The specification should document how to secure JSON using JWT-VCs and mapping between the claims since many use cases today are creating JWS (JAdES) signatures. If this specification doesn't cover the topic, there's a risk of having multiple profiles.
My question above has been answered in discussion in https://github.com/w3c/vc-data-model/pull/1088
Essentially, the proposal here is compliant with definitions of JWT and JWS.
I'm not sure about the 'typ' property: "typ": "vc+ld+jwt"
according to the RFC7515
The "typ" value "JOSE" can be used by applications to indicate that this object is a JWS or JWE using the JWS Compact Serialization or the JWE Compact Serialization. The "typ" value "JOSE+JSON" can be used by applications to indicate that this object is a JWS or JWE using the JWS JSON Serialization or the JWE JSON Serialization. Other type values can also be used by applications.
Hence, if my understanding is correct, the typ should be: vc+ld+JOSE or vc+ld+JOSE+JSON
The model should be fully compatible with the SD-JWT selective disclosure.
RFC7515 already secures an arbitrary JSON. Signature profiles are then further defined by OIDC for the id token, JAdES for advanced signatures - note that JAdES fully secures ANY JSON, regardless of the content or the data model; etc.
The specification should document how to secure JSON using JWT-VCs and mapping between the claims since many use cases today are creating JWS (JAdES) signatures. If this specification doesn't cover the topic, there's a risk of having multiple profiles.
This work is being done elsewhere, see: draft-prorock-jose-native-jwt-vcs-00 - will be replaced by a version likely merging terbu draft below draft-terbu-sd-jwt-vc-02 - will likely contain all changes from above, with sd-jwt stuff and a related PR
We should merge this PR @brentzundel @Sakurann @selfissued @OR13 Then we can proceed to name this spec VC-xOSE or something and have it cover explicitly (per charter) securing the core data model with JOSE and COSE
I support merging this PR.
The specification should document how to secure JSON using JWT-VCs and mapping between the claims since many use cases today are creating JWS (JAdES) signatures. If this specification doesn't cover the topic, there's a risk of having multiple profiles.
@mprorock Please check comment: https://github.com/w3c/vc-jwt/pull/88#issuecomment-1591910039. Ignore the one you quoted.
I agree with the VC-*OSE
- Hence, the document should be titled securing VCs with JWS
I agree with this. Also see https://github.com/w3c/vc-jwt/issues/12.
The issue was discussed in a meeting on 2023-06-21
This scopes vc-jwt spec to securing JSON-LD payload, which I think it a good step forward. securing vanilla JSON payload using JWTs should continue elsewhere.
updated on june-29: the original hope of MSFT when joining VC WG v2.0 last year was to work on improving how vc-jwt specification can be used to secure vanilla JSON, but the WG over the course of last year made it very clear that it is not interested in doing so, nor it has sufficient expertise to do so. hence the comment above.
I think it's wise for the working group to focus on doing 1 content type well, and letting other working groups focus on other content types.
@OR13 do you mind putting some extra eyes in to make sure i resolved conflicts correctly and didn't miss anything?
@selfissued are you still wanting changes to this PR?
If yes, @OR13 perhaps we should discuss briefly during the WG call next week?
I removed the labels related to external review... I am hopeful we can clean this up eventually.
Conflicts exist.
I suggest we merge this PR before merging any others, its making it very difficult to maintain the spec, and the sections in question are not needed.
@mprorock —
It appears that we need you to resolve the conflicts on this PR, and then maybe @selfissued (who still has an open change request, according to the reviewers list) should re-review, so it can be merged...
@OR13 please double check that i resolved conflicts correctly - as you noted this PR is a blocker and I really can't do any work until this is in.
Chairs - @brentzundel @Sakurann can we get consensus on this so we can merge - otherwise we are blocked from further work on prepping this item for CR
Remove securing json section - focus on securing core data model
Preview | Diff