Feature/editorial expansions

[mprorock]

Beginning to add text to section headings, security considerations, etc

---

Preview | Diff

[mprorock]

Note - not super happy about the way the examples read out in various sections, but will address that in a future PR for example heavy sections.

[dlongley]

@Sakurann,

relationship with JWT should peobably be clearer. probably something like the following is needed: "VC-JWT can be used with any JSON-based representation of claims, including JSON-LD."

We should be careful with that specific language. That language can be misinterpreted as "If you use VC-JWT, you can turn any JSON into a VC!" which would certainly result in objections. I'm not quite sure what the goal is, but I expect it can be achieved with slightly different language that won't raise objections. VC-JWT is intended to secure VCs (or alternative representations of VCs that can (therefore) be mapped to application/vc+ld+json) ... not just anything. It wouldn't make sense to call the technology "VC-JWT" otherwise.

I don't think you were trying to imply anything else, I'm just worried about the specific language creating an issue.

The other point to make here may be that it needs to be clear that the cty field indicates whether you've got:

1. a claims set (that follows the same rules that applies to any "claims set" where the IANA registry can be used to understand the claims) that must be able to mapped to application/vc+ld+json or
2. you've got a non-claims-set (you do not use the IANA registry, but rather the context and the VCDM), i.e., you've got application/vc+ld+json directly.

[mprorock]

relationship with JWT should peobably be clearer. probably something like the following is needed: "VC-JWT can be used with any JSON-based representation of claims, including JSON-LD." (inspired by what we put in SD-JWT)

yes - i think that is a much better path - let me work on some language there.

[mprorock]

I have suggestions, but I would happily take the PR without them being applied lots of improvement in here.

thanks for the suggestions in - I have incorporated the bulk of them and opened issues to track items we should address in follow on PRs

[OR13]

@Sakurann requesting another review

[iherman]

The issue was discussed in a meeting on 2023-05-03

• no resolutions were taken

View the transcript

#### 2.7. Feature/editorial expansions (pr vc-jwt#77) _See github pull request [vc-jwt#77](https://github.com/w3c/vc-jwt/pull/77)._ **Brent Zundel:** moving to vc jwt spec. **Orie Steele:** can cover it. … mike p has made a pass on vc jwt and there is a lot of content he is updating. … large PR but very much needed. … spec feels light and a lot of paragraphs build out the feeling of the spec. … personally don't like those sections but acknowledges that other readers prefer that. … a few unresolved suggestions but my feedback is non-blocking. … kristina has requested changes but not sure if mike addressed them? **Brent Zundel:** kristina will re-revieww. … anything else that is vc jwt related that editors want to cover?

[mprorock]

I've left a bunch of suggestions should the consensus be to remove normative language. I encourage doing so, but will not block if the suggestions are not accepted.

merged - thank you

[OR13]

@Sakurann we are still waiting for your concrete change request, we will merge the PR if we don't hear back from you in 1 week.

[iherman]

The issue was discussed in a meeting on 2023-05-10

• no resolutions were taken

View the transcript

#### 1.8. Feature/editorial expansions (pr vc-jwt#77) _See github pull request [vc-jwt#77](https://github.com/w3c/vc-jwt/pull/77)._ **Brent Zundel:** handing things to VC JWT editors vor pull 77. **Michael Prorock:** only one open change request from Kristina and outdated at this point. Has been asked several times. Feel it is ready to merge. … can adjust things with other language later as needed. **Orie Steele:** has asked Kristina several times with a warning recently if no feedback in a week we'd move forward. Not a nice to do for a chair we need to move on. > *Michael Prorock:* "There are three classes of JWT Claim Names: Registered Claim Names, Public Claim Names, and Private Claim Names.". **Dave Longley:** has outstanding change request - think we're asking for trouble if we don't do it. Use the work payload for JSON-LD in the text. The use of the term "claim set'. … highly recommend using "payload" in this spec. **Orie Steele:** have talked about this exact issue of "claim set". When we say this is a 'private claim' one of the understandings is to look at if there is a private claim in the context file. > *Michael Prorock:* +1. **Orie Steele:** previously tried to refer to claim sets as payloads and has been chastised. RFC call this a "claim set". We should use what the RFC defines. … Any JSON object is a valid json payload and valid as a claim set as a token. **Michael Prorock:** notes david's concerns and should be understood. Claim set is about public and private claims which is the word used. > *Phillip Long:* mproprock if we shift this to a more JWS approach the problem would arise. > *Samuel Smith:* As can be imagined to avoid conflicting reasoning paths, complex sets of rules require precedence or weight to be assigned. This method, which helps establish the level of certainty of the expert system’s predictions and recommendations, is referred to as the confidence factor. > *Orie Steele:* Worth noting that using JWS would also support securing content types that are not JSON-LD... it might be nice to secure payloads that are not JSON... JSON Web Tokens, assumes json claimsets.... JSON-LD is sadly also JSON. > *Phillip Long:* dlongely note that private claims should not conflict nor with registered claims-- recommend shifting to more JWS language that problem would go away. > *Orie Steele:* I appreciate the concern, please be clear if you will formally object. > *Michael Prorock:* appreciate dave's approach on this. > *Michael Prorock:* very much. **Brent Zundel:** heard that dave wouldn't block this if we move this to a more JWS approach but he'll leave that to be resolved by the JWS editors. > *Dave Longley:* no formal objection, just raising concerns for VC-JWT editors to figure out how to resolve to avoid potential problems. **Brent Zundel:** assuming Kristina's issue isn't further discussed it should go to the JWS editors. … PR in status list we should look at. … PR 46 or PR 60. > *Orie Steele:* +1.

[OR13]

Lots of approvals, no change requests, except perhaps: https://github.com/w3c/vc-jwt/pull/77#discussion_r1183899708

I am filing this issue to address it in follow up: https://github.com/w3c/vc-jwt/issues/84