<dlongley> scribenick: dlongley
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
<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
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