<dlongley> scribenick: dlongley

Agenda review, Introductions, Re-introductions

burn: We're going to start with reviewing PRs. Then we'll look at issues, we won't start with assigning names to issues and I'll give background on that in a moment. Anyone joining for the first time today?
... Manu would you like to reintroduce yourself?

manu: Hi, I'm Manu Sporny. I work at Digital Bazaar. We've been involved in the VC stuff for quite a while, a number of our products utilize the tech. We work with large gov't, banking, finance, etc customers. Look forward to the spec reaching REC this year.

burn: The chairs and editors have has some more conversations and we'd like to cover a few important points.
... The spec was published as CR last Thursday, yay!

<manu> yaaay! to CR being published :))))

burn: In addition, the group has been extended to the end of September, congratulations to everyone.

<dmitriz> yayyyy!!!

<manu> yaaay! for administrative Charter extension!!!!

burn: This is what we were hoping for and it's confirmed now.
... At this stage, our groups work and the status of our spec is a little at risk. I will put this bluntly. It is at risk from two kinds of people. Those that wish the group to fail and those that believe that what they want is more important than having the group succeed.
... There are 4 ways this can manifest. 1. Trolling of the issues list. Intentionally or unintentionally splitting the group over some issue that's not worth destroying the spec over.
... 2. Trolling of our issues list by proposing unnecessary normative changes that would force us to have another CR.
... 3. Responding slowly to discussions or at the very last moment. Malicious responders will do this to make the group go past its charter time. It can also happen if the group loses focus.
... 4. Someone arguing that someone has not addressed the issue after the group has considered it and made a decision. That can happen sometimes but people who wish the group ill will tend to do this. We have some suspicion that there are people that do feel that way about the group.
... I'm going to go over some more about this. At this point a single normative change will require a new CR. To issue a new one we would need a successful publication vote near the end of May. We'd need wide review by the end of April.
... Here are the guidelines and rules that we plan to follow. Our goal is to not make any normative changes unless absolutely necessary. If we MUST then we need to make them right away. If there's something that really must happen, don't wait.
... For every issue, we will either request or propose non-normative spec changes if possible.
... The reason for this is to provide that we have indeed considered the issue. We will be going from a 14-day default close to a 7-day default close. I'm not happy about this but I think it's the way we'll have to go.
... It doesn't mean that if there is strong objection to the close and that person is on vacation we can't make exceptions.
... But in order to keep the work moving it's dangerous for 14 days ... if you don't respond to close it because people might wait 14 days and then give a comment and then do it again and then we're over time.
... We will open a closed issue but only if new information is brought. This is appropriate at this stage, it is what CR means.
... Ok, thank you.
... Looking for a new scribe...

<scribe> scribenick: gannan

PR review

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

manu: We're going to reference the issues first and then talk about the PRs

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

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

manu: Tony Nadalin raised a concern that issues about private browsing mode in different browsers and he wanted to point out that each browser may or may not have private browsing mode
... Brent addressed the issue in his PR with a non-normative change
... Any objections? If not I will make a proposal.

<manu> PROPOSED: Merge non-normative PR #510 in order to clarify private-browsing mode concerns raised in issue #492.

<dlongley> +1

burn: Focused on closing issues and minimizing discussion. We want to be clear with our resolutions so that they're entered into the minutes.

<brent> +1

<ken> +1

<TallTed> +1

<deiu> +1

<tzviya> +1

<stonematt> +1

<burn> +1

<oliver_terbu> +1

<manu> +1

manu: Ensure that only one representative from the company is adding a +1.

TallTed: In a working group this is not the case, it is one person, one vote.

<stonematt> +1 to call for objections in following resolutions

burn: I would rather not do a vote and just call for objections.

RESOLUTION: Merge non-normative PR #510 in order to clarify private-browsing mode concerns raised in issue #492.

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

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

manu: Next PR has to do with security considerations section, issue 493. Tony is asserting that there are lowercase musts in a non-normative sections. Chaals created a PR with non-normative changes to address Tony's concerns. It changes text from "must" to "needs to"

<manu> PROPOSED: Merge non-normative PR #499 in order to clarify that existing 'must' was not a normative statement, which was raised in issue #493. Close issue #493 after the merge.

manu: any objections to that proposal?

RESOLUTION: Merge non-normative PR #499 in order to clarify that existing 'must' was not a normative statement, which was raised in issue #493. Close issue #493 after the merge.

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

manu: PR for token binding, issue 495

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

manu: ... Tony is requesting we link to RFC ???, we have a PR that updates a link to the specification

<manu> PROPOSED: Merge non-normative PR #497 in order to update to an informative reference to RFC8471 raised in issue #495. Close issue #495 once the PR is merged.

manu: any objections?

RESOLUTION: Merge non-normative PR #497 in order to update to an informative reference to RFC8471 raised in issue #495. Close issue #495 once the PR is merged.

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

manu: Next item, issue 482. Tony asserts that the introduction is misleading because it talks about digital signatures...
... ...our specification doesn't standardize on proof formats

<manu> PROPOSED: Add more clarifying text to the specification noting that while the specification does not standardize on signature format, the WG is aware of at least three mechanisms (JWTs, LD-Proofs, and ZKPs) that are capable of protecting the contents of the data model at the time of publication that are being used in deployments of the technology and expects those mechanisms to mature independently as well as new mechanisms to become standardized.

manu: ...we would make a non normative clarification to the spec
... ...the spec already states that we are not choosing one signature mechanism, we are proof agnostic
... any objections?

Justin_R: no objections, I think it is the right way to go. I want to make sure that the existing text does veer towards LD as the base model...
... ...and everything else is an expression of the LD model

<jonathan_holt> 1+

manu: can you suggest in the issue or in the PR some concrete non-normative spec changes?

Justin_R: sure, could you tag me as a reviewer so I can look at it. To prevent stepping on each others toes.

burn: Let's make sure we can do that.

Justin_R: Or a comment.

manu: Taking note of that.

Justin_R: Thank you.

manu: any objections?

RESOLUTION: Add more clarifying text to the specification noting that while the specification does not standardize on signature format, the WG is aware of at least three mechanisms (JWTs, LD-Proofs, and ZKPs) that are capable of protecting the contents of the data model at the time of publication that are being used in deployments of the technology and expects those mechanisms to mature independently as well as new mechanisms to become standardized.

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

manu: next, section 4.1 @context... issue 483
... ...tony has asserted that there is no reason to have a @context, it should be removed or made optional
... ...there has been a lot of discussion around interop between json only and json-ld processors
... ...we've been discussing this for a long time and the points that Tony raised has been discussed by the working group
... ...the working group made a vote to make @context mandatory in our f2f meeting with broad agreement
... ...you do not need to process @context when using a JSON only processor

<manu> PROPOSED: The VCWG had considered all points raised by issue #483 throughout the lifetime of the WG's operation, no new information was provided by issue #483 to convince the WG to change @context being mandatory (which has broad support in the WG with no objections), and thus the issue should be closed with no changes to the specification.

manu: any objections?

jonathan_holt: It goes into the mime-type discussion we had in Barcelona, we should require @context

manu: To be clear you are saying that this is part of the conversation, you are not rejecting the proposal
... that is a formal objection, we are requiring @context

<dlongley> the `@context` is on the `vc` .. not on the JWT. ... is this a clarification we need?

jonathan_holt: we should be specific on when @context is required

manu: we need some spec text

jonathan_holt: I'll bubble up my issue

<Zakim> brent, you wanted to say text clarification that explicitly points out that if the data model is encoded as a JWT, no processing of the @context is expected may be helpful

burn: It might be more efficient to have a conversation

brent: I think it we added some text that clarifies if the data model is processed as a JWT then no processing of @context is needed
... @context needs to be present but need not be processed by their processor

manu: we can't proceed... need to have a conversation with jonathan_holt... brent go ahead and write a PR with this issue and potentially others

TallTed: what I'm seeing in this issue thread, is not an issue about processing the @context content. It's about someone working exclusively with JWT's and do not want to have @context in their credential and they have no care for JSON-LD

manu: It's necessary for the data encapsulated in the JWTs, if it's not in the VC then it's semantically ambiguous

TallTed: That needs to be addressed

manu: That is addressed in issue 491

<dlongley> +1 it's not about JWT, it's about the payload IN the JWT.

TallTed: We need to address what others that don't understand, @context should be in the payload in the JWT

manu: We'll refer to this in the issue

Justin_R: It sounds like that fundamentally a VC is JSON-LD doc with many types of expression
... ... if that's the case then we need to be explicit, if not then these issues do have merit

manu: It's not just a JSON-LD document, it's a hybrid. We have something that could just use JSON processing or JSON-LD processing

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

manu: this needs more discussion
... In the next issue, has to do with content integrity
... Tony says there is no need to have content integrity in JWTs
... This is talking about links in documents, we warn that outgoing links need content integrity, JWTs do not solve that problem

<manu> PROPOSED: The content-integrity section of the specification describes how outgoing links from a document may be protected. Issue #494 asserts that JWTs provide content-integrity protection for outgoing links, which is false.The VCWG is also supportive of the use of @context as a core part of the data model. Issue #494 should be closed with no changes to the specification.

manu: Basically, no change to the spec. It's a non-normative section, we are not saying you need to have content integrity for outgoing links but recommend a few mechanisms to achieve this
... any objections?

RESOLUTION: The content-integrity section of the specification describes how outgoing links from a document may be protected. Issue #494 asserts that JWTs provide content-integrity protection for outgoing links, which is false.The VCWG is also supportive of the use of @context as a core part of the data model. Issue #494 should be closed with no changes to the specification.

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

manu: next is issue 498, Tony says that there are no interoperable parts of the spec that makes it verifiable

<TallTed> TallTed: "JWTs provide content-integrity protection for outgoing links" = true. "JWTs provide content-integrity protection for content of outgoing links" = false.

manu: ...remove verifiable from the spec and make JWTs the normative way of expressing credentials
... ...the issue is about the title of the specification and removing the word verifiable

<manu> PROPOSED: The specification clearly defines the meaning of "verifiable credential" and the VCWG has spent a considerable amount of time discussing and running surveys on the proper name for the specification. The VCWG believes the name of the specification is appropriate. Issue #498 should be closed with no change to the title of the specification.

manu: ...the group has had a long discussion and agreed that it should be the "Verifiable Credentials" data model
... any objections?

RESOLUTION: The specification clearly defines the meaning of "verifiable credential" and the VCWG has spent a considerable amount of time discussing and running surveys on the proper name for the specification. The VCWG believes the name of the specification is appropriate. Issue #498 should be closed with no change to the title of the specification.

<dlongley> https://github.com/w3c/vc-data-model/issues/502

manu: next is a charter comment. Tony is mentioning that the web-authn should have been a liason in the charter. He wants to have a charter update. We just got a charter extension so we can't change the charter. Tony is the co-chair of the group and has made a full review of the specification already. The Web Authn group has the ability to do any additional reviews

burn: we are not changing the charter
... we do not need a formal liason relationship for comments to be made on the specification

<manu> PROPOSED: The VCWG notes that the charter cannot be changed at present and thus new Liaison relationships cannot be added. The VCWG also notes and is thankful of the review of the specification that has been performed by Tony Nadalin, who is a co-chair of the WebAuthn WG, and welcomes comments from all interested Working Groups. Issue #513 should be closed with no change to the specification.

manu: this is the new re-worked proposal?

burn: any objections?

RESOLUTION: The VCWG notes that the charter cannot be changed at present and thus new Liaison relationships cannot be added. The VCWG also notes and is thankful of the review of the specification that has been performed by Tony Nadalin, who is a co-chair of the WebAuthn WG, and welcomes comments from all interested Working Groups. Issue #513 should be closed with no change to the specification.

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

kaz: The first two proposals should be removed from the minutes later because they're overridden by the third proposal

manu: correct

(Originally there were three proposals made during the call, but the first two proposals have been removed and only the final proposal confirmed is recorded above)

manu: Tony says that JWKs should be listed as a normative reference, brent and oliver had a back and forth in the comments. It seems that JWKs are not listed

<manu> PROPOSED: Add non-normative text to the specification that makes an informative reference to the JWK specification and notes that key discovery can be performed in a variety of ways including the use of JWK and DID-based key discovery.

manu: ...the suggestion is to make a non-normative spec change that points to JWK as a way to describe keys but not the only way
... any objections to that proposal?

<Justin_R> +1 informative references to examples are good

<Justin_R> (I had raised this previously)

RESOLUTION: Add non-normative text to the specification that makes an informative reference to the JWK specification and notes that key discovery can be performed in a variety of ways including the use of JWK and DID-based key discovery.

<Justin_R> np

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

Justin_R: going to tag you in the resolution, since you had some concerns

manu: issue 490, this is about the Trust Model. Section 5.2 which is non-normative. We talk about what the Trust Model should be, it's not the only one
... tony suggests that this should be put at-risk, I've seen no spec that has put non-normative text as at-risk
... nothing in this section has implementation burden so there's no reason to mark it at risk

<manu> PROPOSED: Section 5.2: Trust Model is a non-normative section on the specification. Issue #490 asserts that it should be marked at risk. Non-normative sections contain no normative statements and thus are not at risk during or after the Candidate Recommendation phase. Issue #490 should be closed with no changes to the specification.

manu: it's a no change to the specification

<TallTed> +1 non-normative, so no implementation expected, so can't be at-risk

burn: at risk as I understood it during my 20years, at risk means at risk from removal from the specification due to insufficient implementation

kaz: just want to confirm that the feature we're discussing wouldn't impact implementations

(burn agrees that is a good point, and doesn't think it would impact implementations)

manu: any objections?

RESOLUTION: Section 5.2: Trust Model is a non-normative section on the specification. Issue #490 asserts that it should be marked at risk. Non-normative sections contain no normative statements and thus are not at risk during or after the Candidate Recommendation phase. Issue #490 should be closed with no changes to the specification.

manu: do the chairs want to wrap up or process one more issue?

burn: it'd be good to wrap up

Any other business?

Kaliya mentions she and Heather have published a book which has a chapter on Verifiable Credentials

burn: any questions or comments before we end the call?

yancy: just wanted to say I raised a few issues on the test suite, would like some responses

burn: we need to discuss this, test could change because they were implemented incorrectly or there was an update to normative references

dmitriz: can we work on it next call?

burn: would prefer to continue it offline
... to short notice, but the chairs can talk about a way too have more working calls between our meetings
... thank you everyone, bye