<burn> scribenick: TallTed

plan/agenda

burn: we'll start with PR announcements (mostly not decision-making), and move into an "issue lightning round" to quickly close what we can
... not to run over disagreements -- discussion can be scheduled for another call
... proposing increasing call duration to 2 hours

burn: with a shift to start 1 hour earlier

<manu> +1 to starting call 1 hour earlier.

<stonematt> +1 to starting earlier

<manu> also, fwiw -- +1 to running call for extra hour today.

<jonathan_holt> +1 but starting next week

<DavidC> +1

<dlongley> +1 fine with doing it this week

<jonathan_holt> I don't want to miss the CCG meeting

<ken> -1 for today

<Zakim> manu, you wanted to ask about overlap?

<ken> +1 starting next week

<manu> current CCG agenda - TL;DR: EOY Survey Results, cont'd and Code of Conduct and Conflict Management (if time permits)

PR announcements

<manu> https://github.com/w3c/vc-data-model/pulls

manu: we have an increasing backlog, including 5 large PRs from grant noble
... these will cause merge conflicts with every other PR ... which will need to be fixed ASAP

<manu> https://github.com/w3c/vc-data-model/pull/539

<manu> https://github.com/w3c/vc-data-model/pull/550

<manu> https://github.com/w3c/vc-data-model/pull/542

manu: generally in good shape -- ready to merge or discussion is ongoing

<manu> https://github.com/w3c/vc-data-model/pull/542/files

manu: asserting that PR#542 is a bug-fix to normative text

[ no objections to assertion ]

manu: any other concerns on PRs? need extra call time for any PR?

[ silence ]

Issue lightning round: close the issues we can

<Justin_R> @manu -- I looked just now and there was one line that I'd missed from your comments (it was right next to another line that was fixed and I missed the repeated term).

<Justin_R> Everything else is in there though so please review

<Justin_R> This is for #539

<burn> https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Adefer

manu: these are all proposals; primarily looking for objections

<manu> https://github.com/w3c/vc-data-model/pull/542/files

<manu> https://github.com/w3c/vc-data-model/issues/520

manu: issue suggests using a JWK (seems really to mean JWT) as a VC
... WG has clarified that a JWT is not a VC, but a JWT can be used to secure a VC

manu: language around context processing is being clarified

<manu> PROPOSED: A JWT is not a Verifiable Credential as the data models differ. A JWT can be used to secure a Verifiable Credential as described in Section 6.3.1. The language related to @context processing for JWT-based processors should be clarified to note that dereferencing @context values is not required, which is a non-substantive clarification to the existing text in the specification. The IANA registration for the vc and vp JWT claims should be separated into an IANA Considerations section. Issue #520 should be closed after the PR is merged.

[ no objections ]

RESOLUTION: A JWT is not a Verifiable Credential as the data models differ. A JWT can be used to secure a Verifiable Credential as described in Section 6.3.1. The language related to @context processing for JWT-based processors should be clarified to note that dereferencing @context values is not required, which is a non-substantive clarification to the existing text in the specification. The IANA registration for the vc and vp JWT claims should be separated into an IANA Considerations section. Issue #520 should be closed after the PR is merged.

<manu> https://github.com/w3c/vc-data-model/issues/523

<manu> PROPOSED: One of the goals of the Verifiable Credentials Data Model specification is to define extensibility points in the data model and achieve interoperability on the extensibility points (not the extensions themselves). The interoperability tests will focus on ensuring that the minimum information exists in extensions to identify the extension without needing to define each extension in detail for this iteration of the Working Group. Defining extensions to the base data model is outside of the scope of the WG's charter. All features that the Working Group deems at risk were marked before entering CR. No new at-risk features have been identified after processing issue #523, which should be closed with no changes to the specification.

[ no objections ]

RESOLUTION: One of the goals of the Verifiable Credentials Data Model specification is to define extensibility points in the data model and achieve interoperability on the extensibility points (not the extensions themselves). The interoperability tests will focus on ensuring that the minimum information exists in extensions to identify the extension without needing to define each extension in detail for this iteration of the Working Group. Defining extensions to the base data model is outside of the scope of the WG's charter. All features that the Working Group deems at risk were marked before entering CR. No new at-risk features have been identified after processing issue #523, which should be closed with no changes to the specification.

<manu> https://github.com/w3c/vc-data-model/issues/524

<manu> PROPOSED: The VCWG seeks to demonstrate interoperability at the data model and extension points in the specification, not the extensions themselves as the group is not chartered to work on extensions. The VCWG has reviewed all conformance statements, has implemented a test suite that tests all required conformance statements in the specification, and asserts that this approach is appropriate for a data model specification. Section 5.3 should be marked as

<manu> non-normative as it does not contain any normative statements. Section 5.3.1 should remain normative. These are non-substantive changes and once they are made, issue #524 should be closed.

scribenick: dlongley

TallTed: Section 5.3 cannot be non-normative if Section 5.3.1 is normative. You can't have a non-normative section with normative subsections.

burn: You can do it the other way around though.

manu: I defer to you, Ted. I thought you could have massive non-normative sections and mark subsections as normative.

<rhiaro> Logically what Ted says makes sense to me

<brent> +1 to TallTed

TallTed: I don't believe so. Unless you have huge red flags at the top that say there's some tiny section that is normative.
... But that doesn't really work out.

<dlongley> manu writes up a new proposal

<burn> Ted is right. Implementers read 'non-normative' at the top and ignore the contents. The reverse is okay, labeling normative at the top and having subsections be non-normative

<burn> The end result is the same either way, just better understood

TallTed: To be clear, it is fine to put into each of the other subsections that it is non-normative.

manu: But that's not the case we have here, it's the opposite.

TallTed: It's not ok to have 5.3 non-normative and 5.3.1 as normative, but we can individually label subsections as non-normative. 5.3 normative, 5.3.1 normative, 5.3.2 non-normative, 5.3.3 non-normative, etc -- it just needs to be labeled individually.

<Justin_R> +1 to Tall_Ted's suggestion

burn: Let's take this offline. Ted is correct, but the end result is the same as what you want. You can't have a normative within a non-normative.

<manu> PROPOSED: The VCWG seeks to demonstrate interoperability at the data model and extension points in the specification, not the extensions themselves as the group is not chartered to work on extensions. The VCWG has reviewed all conformance statements, has implemented a test suite that tests all required conformance statements in the specification, and asserts that this approach is appropriate for a data model specification. Section 5.3 should remain normative as it contains a normative section 5.3.1. Section 5.3.1 should remain normative. Other PRs are in process that clarify the findings of this proposal and once they are made, issue #524 should be closed.

manu: There are no sections 5.3.2+.

<kaz> section 5.3

scribenick: TallTed

[ no objections ]

RESOLUTION: The VCWG seeks to demonstrate interoperability at the data model and extension points in the specification, not the extensions themselves as the group is not chartered to work on extensions. The VCWG has reviewed all conformance statements, has implemented a test suite that tests all required conformance statements in the specification, and asserts that this approach is appropriate for a data model specification. Section 5.3 should remain normative as it contains a normative section 5.3.1. Section 5.3.1 should remain normative. Other PRs are in process that clarify the findings of this proposal and once they are made, issue #524 should be closed.

<manu> https://github.com/w3c/vc-data-model/issues/525

<manu> PROPOSED: Non-normatively elaborate on the JSON Verifiable Credential processor rule that ensures that the array of values associated with @context should be in the expected order for the processor. Close issue #525 after the PR has been merged.

<manu> PROPOSED: Editors will non-normatively elaborate on the rules that ensure that the array of values associated with @context should be in the expected order. Close issue #525 after the PR has been merged.

[ no objection ]

RESOLUTION: Editors will non-normatively elaborate on the rules that ensure that the array of values associated with @context should be in the expected order. Close issue #525 after the PR has been merged.

<manu> https://github.com/w3c/vc-data-model/issues/394

<manu> PROPOSED: Multiple non-normative commits and PRs (#475, #499) have been written, reviewed and applied for this issue. The WG does not believe that any more mis-characterized normative terminology appears in non-normative sections. Issue #394 should be closed.

[ no objection ]

RESOLUTION: Multiple non-normative commits and PRs (#475, #499) have been written, reviewed and applied for this issue. The WG does not believe that any more mis-characterized normative terminology appears in non-normative sections. Issue #394 should be closed.

<manu> https://github.com/w3c/vc-data-model/issues/462

<manu> PROPOSED: Issue #462 is addressed by PR #503, which makes non-normative changes detailing type information stored in a credential as requested by the reviewer. The PR has been approved by multiple parties and has been merged. Issue #462 should be closed.

[ no objection ]

RESOLUTION: Issue #462 is addressed by PR #503, which makes non-normative changes detailing type information stored in a credential as requested by the reviewer. The PR has been approved by multiple parties and has been merged. Issue #462 should be closed.

<manu> https://github.com/w3c/vc-data-model/issues/463

<manu> PROPOSED: Issue #463 is addressed by PR #504, which makes non-normative changes to updated the definition of an entity requested by the reviewer. The PR has been approved by multiple parties and has been merged. Issue #463 should be closed.

[ no objection ]

RESOLUTION: Issue #463 is addressed by PR #504, which makes non-normative changes to updated the definition of an entity requested by the reviewer. The PR has been approved by multiple parties and has been merged. Issue #463 should be closed.

<manu> https://github.com/w3c/vc-data-model/issues/464

<manu> PROPOSED: Issue #464 is addressed by PR #512, which makes non-normative changes related to the subject of the credential as requested by the reviewer. The PR has been approved by multiple parties and has been merged. Issue #464 should be closed.

[ no objection ]

RESOLUTION: Issue #464 is addressed by PR #512, which makes non-normative changes related to the subject of the credential as requested by the reviewer. The PR has been approved by multiple parties and has been merged. Issue #464 should be closed.

<manu> https://github.com/w3c/vc-data-model/issues/466

<manu> PROPOSED: Issue #466 is addressed by PR #477, which makes minor non-normative changes by changing "might perform" to "performs" for certain roles as requested by the reviewer. The PR has been approved by multiple parties and has been merged. Issue #466 should be closed.

[ no objection ]

RESOLUTION: Issue #466 is addressed by PR #477, which makes minor non-normative changes by changing "might perform" to "performs" for certain roles as requested by the reviewer. The PR has been approved by multiple parties and has been merged. Issue #466 should be closed.

<manu> https://github.com/w3c/vc-data-model/issues/471

<manu> PROPOSED: Issue #471 is addressed by PR #507, which makes non-normative changes pointing out that trust is bilateral between issuers and verifiers as requested by the reviewer. The PR has been approved by multiple parties (including the reviewer), and has been merged. Issue #471 should be closed.

[ no objection ]

RESOLUTION: Issue #471 is addressed by PR #507, which makes non-normative changes pointing out that trust is bilateral between issuers and verifiers as requested by the reviewer. The PR has been approved by multiple parties (including the reviewer), and has been merged. Issue #471 should be closed.

<inserted> (burn suggest we extend the VCWG call today by 15 mins at max to finish out the issue list)

<TallTed> +1 finish out the list

<stonematt> +1 to finish the list

<dlongley> +1 to finish the list

<brent> +1 to continuing the VCWG call

<manu> +1, let's go finish the list! :)

<SercanK> +1 finish the list

<manu> https://github.com/w3c/vc-data-model/issues/472

<manu> PROPOSED: Issue #472 is addressed by PR #476, which makes non-normative changes noting that consent isn't implied by signatures on presentations as requested by the reviewer. The PR has been approved by multiple parties and has been merged. Issue #472 should be closed.

[ no objection ]

RESOLUTION: Issue #472 is addressed by PR #476, which makes non-normative changes noting that consent isn't implied by signatures on presentations as requested by the reviewer. The PR has been approved by multiple parties and has been merged. Issue #472 should be closed.

<manu> https://github.com/w3c/vc-data-model/issues/481

<manu> PROPOSED: Issue #481 is addressed by PR #508 and PR #509, which make multiple non-normative changes to the definitions of roles in the ecosystem as requested by the reviewer. The PR has been approved by multiple parties and have been merged. Issue #481 should be closed.

[ no objection ]

RESOLUTION: Issue #481 is addressed by PR #508 and PR #509, which make multiple non-normative changes to the definitions of roles in the ecosystem as requested by the reviewer. The PR has been approved by multiple parties and have been merged. Issue #481 should be closed.

<manu> https://github.com/w3c/vc-data-model/issues/485

<manu> PROPOSED: Issue #485 is addressed by PR #519, which makes non-normative changes noting that a JWK can also be used in the place of an `issuer` property as requested by the reviewer. The PR has been approved by multiple parties and has been merged. Issue #485 should be closed.

[ no objection ]

RESOLUTION: Issue #485 is addressed by PR #519, which makes non-normative changes noting that a JWK can also be used in the place of an `issuer` property as requested by the reviewer. The PR has been approved by multiple parties and has been merged. Issue #485 should be closed.

<manu> https://github.com/w3c/vc-data-model/issues/541

<manu> PROPOSED: Issue #541 is addressed by PR #542, which makes a non-substantive change that fixes a bug in the specification related to JWT jti/sub values being swapped. This is a non-substantive change because there were two conflicting normative statements in the specification, the examples were clearly the intent, and any reasonable implementer would have implemented the feature correctly based on the existing JWT encoding rules in the specification. The PR has been approved by multiple parties as a non-substantive change and should be merged. Issue #541 should be closed after the PR is merged.

[ no objection ]

RESOLUTION: Issue #541 is addressed by PR #542, which makes a non-substantive change that fixes a bug in the specification related to JWT jti/sub values being swapped. This is a non-substantive change because there were two conflicting normative statements in the specification, the examples were clearly the intent, and any reasonable implementer would have implemented the feature correctly based on the existing JWT encoding rules in the specification. The PR has been approved by multiple parties as a non-substantive change and should be merged. Issue #541 should be closed after the PR is merged.

manu: that ends the list of issues with pending PRs ...

<stonematt> thank you, thank you, thank you to everyone!

<dlongley> +1

<DavidC> I will also be away next week so I might not be able to attend either

burn: manu will be on vacation for the next week, so we expect not to process spec issues next week; instead, focus on the implementation guide and registry
... please do continue offline work on issues (outside of calls)

adjourned