Minutes for VCWG telecon 30 April 2019 from Kazuyuki Ashimura on 2019-05-01 (public-vc-wg@w3.org from May 2019)

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Wed, 1 May 2019 17:47:32 +0900
To: public-vc-wg@w3.org
Message-ID: <CAJ8iq9U5Bz_2wm_DfxhE3ZbHb+Bqp_u8FXZ096amaOnJ+7k=kw@mail.gmail.com>

available at:
https://www.w3.org/2019/04/30-vcwg-minutes.html

also as text below.

Thanks a lot for taking these minutes, Dave and Manu!

Kazuyuki

---

[1]W3C

[1] http://www.w3.org/

- DRAFT -

Verifiable Claims WG Teleconference

30 Apr 2019

[2]Agenda

[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Apr/0029.html

Attendees

Present
Amy_Guy, Andrei_Sambra, Benjamin_Young, Brent_Zundel,
Dan_Burnett, Dave_Longley, Dmitri_Zagidulin,
Ganesh_Annan, Kaz_Ashimura, Ken_Ebert, Manu_Sporny,
Matt_Stone, Sercan_Kum, Ted_Thibodeau, Yancy_Ribbens

Regrets

Chair
Matt_Stone

Scribe
manu, dlongley

Contents

* [3]Topics
1. [4]Agenda and planning
2. [5]Issue Lightning Round
3. [6]Raising Issues for Common Issues
4. [7]Implementation Reports and Questions
* [8]Summary of Action Items
* [9]Summary of Resolutions
__________________________________________________________

Agenda and planning

<manu> scribe: manu

stonematt: Quick Agenda review ... back to processing issues
and PRs.
... We're dealing w/ churn of issues coming out from Tony from
Microsoft...

<dlongley> scribenick: dlongley

burn: Every group does need to be able to say "We're moving on"
(end of comment period), that doesn't mean you can ignore
issues that are outstanding but there does need to be an end at
some point.

stonematt: We're trying to get to a point with integrity where
we can say the window for comments is over and we can move on
from here.

manu: A lot of these issues really boil down to a couple of
core philosophical disagreements. The first one has to do with
whether or not JSON-LD processing is required, it is not. We
should raise an issue for that.
... The second one has to do with making the specification
purely an extension of JWTs. The group has decided not to do
that, the VC data model is different from the JWT model.
... The third is extension points in the specification, whether
or not the group was chartered to define the extension points
or define how they would work that would delve into protocol.

<burn> I think the JWT issue stems from interop concern, or is
at least motivated by it

manu: We can direct the current open issues at one of those
three issues.

burn: Every time that issue has come up (interop concern), the
context has been, you guys have no interop, you need to pick
something and the thing you need to pick is JWTs.
... The basis is to say that it is Tony's claim that it is the
only technology that is sufficiently well developed to use to
provide interop.
... Proof format, not technology.
... We could make three separate issues, but I'd definitely
want to have a statement in that one that says that's our
belief.

manu: Yes, I could nitpick ... I'd rather have three topics.

burn: That's fine, if it comes down to it, in a transition
request we'll have to list the disagreements that are
outstanding and I'm ok with those three and that those
represent the sum total of the disagreements reflected across
the sum total of the issues.

manu: So, Dan, you'll write those three?

burn: I'll write up drafts and run them by the two of you.

stonematt: We can write them in a google doc and share the
link.

manu: +1

<dlongley> +1

burn: Not trying to hide anything, just trying to be efficient
and a google doc is a great place to do it.

manu: Bonus points for whomever creates a google doc and puts
the link in IRC.

stonematt: I can do that.
... Any other comments on this topic today?

<ken> +1

Issue Lightning Round

stonematt: We want to close the issues we can. Manu you've been
leading this discussion and I'll hand it over to you.

manu: We've got 15 issues to process today.
... I'll go back to one we weren't able to get closure on.

<manu> [10]https://github.com/w3c/vc-data-model/issues/484

[10] https://github.com/w3c/vc-data-model/issues/484

manu: The issue submitter says the type system is the same as
the one for JSON-LD and that we shouldn't be forced into
JSON-LD and allow for JWTs and CWTs and there are many parsers
out there for JWT/JWS, etc.

<manu>
[11]https://github.com/w3c/vc-data-model/issues/484#issuecommen
t-479922835

[11] https://github.com/w3c/vc-data-model/issues/484#issuecomment-479922835

manu: The discussion goes on for a while and then at the very
end the issue submitter says... This won't work without changes
to the specification which is effectively no JSON-LD statements
would be allowed, no `@context`, and JWT claims are allowed,
JWS/E as proofs and there are other things that will need to be
documented to allow JWT claims to be used.

manu reads proposal for addressing the issue

<manu> PROPOSED: The type system described in the specification
does not require a JSON-LD processor to be used and the
concerns raised in issue #484 have been demonstrated to be
expressible in JWTs using the VC Data Model in a way that is
both conformant with JWTs as well as other expression
mechanisms. No technical examples have been provided that
demonstrate that the type system used for the Verifiable
Credentials Data Model either 1) requires a JSON-LD processor
to

<manu> process, or 2) causes any known JWT library to fail to
process a JWT containing type information (or any other known
markup used in the Verifiable Credentials specification).

<manu> PROPOSED: The WG believes that the type system described
in the specification does not require a JSON-LD processor to be
used and the concerns raised in issue #484 have been
demonstrated to be expressible in JWTs using the VC Data Model
in a way that is both conformant with JWTs as well as other
expression mechanisms. No technical examples have been provided
that demonstrate that the type system used for the Verifiable
Credentials Data Model either 1) requires a

<manu> JSON-LD processor to process, or 2) causes any known JWT
library to fail to process a JWT containing type information
(or any other known markup used in the Verifiable Credentials
specification). No changes should be made to the specification.

<TallTed> +1

<dlongley> +1

<ken> +1

<stonematt> +1

<deiu> +1

RESOLUTION: The WG believes that the type system described in
the specification does not require a JSON-LD processor to be
used and the concerns raised in issue #484 have been
demonstrated to be expressible in JWTs using the VC Data Model
in a way that is both conformant with JWTs as well as other
expression mechanisms. No technical examples have been provided
that demonstrate that the type system used for the Verifiable
Credentials Data Model either 1) requires a

<SercanK> +1

manu: Second proposal has to do with that list of things that
the issue submitter wanted removed from the spec.

<manu> PROPOSED: The WG has considered the proposals raised in
Issue #484 and continues to support both JWTs and JSON-LD in
the specification, continues to support the use of @context as
it exists in the specification today, supports any valid JWT
claim expressed in a JWT-based serialization, and supports the
use of JWS with the specification. The WG has discovered no
technical reason that JWE cannot also be used to encrypt data
expressed in the specification. Issue

<manu> #484 should be closed with no changes to the
specification.

<dlongley> +1

<TallTed> +1

<ken> +1

<SercanK> =1

<SercanK> +1

RESOLUTION: The WG has considered the proposals raised in Issue
#484 and continues to support both JWTs and JSON-LD in the
specification, continues to support the use of @context as it
exists in the specification today, supports any valid JWT claim
expressed in a JWT-based serialization, and supports the use of
JWS with the specification. The WG has discovered no technical
reason that JWE cannot also be used to encrypt data expressed
in the specification. Issue

<manu> #484 should be closed with no changes to the
specification.

<manu> [12]https://github.com/w3c/vc-data-model/issues/458

[12] https://github.com/w3c/vc-data-model/issues/458

Side note: Digital Bazaar is using JWE to encrypt VCs today!

manu: This issue has to do with the refresh service.
... There are multiple PRs related to this.
... So we're just verifying that you were ok with the changes
there, Ken.

ken: There was a different PR that went in and I felt that the
issue was done.

manu: So you feel this issue is done.

ken: Yeah, I wrote the other PR and got review and it was
merged.

manu: PR 501 was replaced by PR 544.

brent: PR 540 was Ken's it got replaced by PR 544.

manu: Based on all that, are you ok to close? I've got a
proposal to close.

manu reads proposal

manu: Would you object to the proposal, Ken?

<manu> PROPOSAL: Issue #458 is addressed by PR #544, which
makes non-normative changes noting when it is and is not
appropriate to use the refresh service. The PR has been
approved by multiple parties and has been merged. Issue #458
should be closed.

ken: Can I have a few minutes to review?

manu: Yes, we'll mark that and come back to it.

<manu> [13]https://github.com/w3c/vc-data-model/issues/470

[13] https://github.com/w3c/vc-data-model/issues/470

manu: This was raised by Justin. He said JWS examples use
detached methods while JWT uses JWS, the detached serialization
mechanism isn't mentioned in this doc or the linked LD proof
docs. Dave Longley asked if it would be ok to add informative
links after the examples and Justin said it would be
sufficient.

<manu> PROPOSAL: Issue #470 should be addressed by making a set
of non-normative changes to the specification that adds a
simple note after each RsaSignature2018 example with an
informative reference to that spec and that mentions it used a
JWS detached signature with an informative reference to the JWS
spec. Issue #470 should be closed after the PR is merged.

<TallTed> +1

manu: Justin was having a hard time tracking down which specs
were being used and we need to point those out in an
informative capacity.

<dlongley> +1

<deiu> +1

RESOLUTION: Issue #470 should be addressed by making a set of
non-normative changes to the specification that adds a simple
note after each RsaSignature2018 example with an informative
reference to that spec and that mentions it used a JWS detached
signature with an informative reference to the JWS spec. Issue
#470 should be closed after the PR is merged.

stonematt: Hearing no objections, it is resolved.

(Kaz joins)

<manu> [14]https://github.com/w3c/vc-data-model/issues/474

[14] https://github.com/w3c/vc-data-model/issues/474

<manu>
[15]https://github.com/w3c/vc-data-model/issues/474#issuecommen
t-481693698

[15] https://github.com/w3c/vc-data-model/issues/474#issuecomment-481693698

manu: Raised by David Chadwick, he's asking whats the
difference between using `credentialSchema` and the `@context`
property. I outlined the changes we could make to the
specification, he hasn't responded to that yet. My expectation
is that he'd be ok with that. He had a list of changes he'd
like to see and we need a PR to address those. Specifically...

<manu> PROPOSAL: Issue #474 should be addressed by making a set
of non-normative changes to the specification that clarifies
the use of @context, the differences between it and the
credentialSchema property, with appropriate references to more
detailed explanations in the specification and other
specifications. Issue #474 should be closed after the PR is
merged.

manu: For example, one of the things he wanted clarified is a
JSON-LD thing and we can just point to that spec for that
particular item. These are all non-normative changes to address
his concerns and we need to write a PR for that.

<dlongley> +1

<TallTed> +1

<deiu> +1

stonematt: Any objections?

RESOLUTION: Issue #474 should be addressed by making a set of
non-normative changes to the specification that clarifies the
use of @context, the differences between it and the
credentialSchema property, with appropriate references to more
detailed explanations in the specification and other
specifications. Issue #474 should be closed after the PR is
merged.

stonematt: No objections, proposal is resolved.

<manu> [16]https://github.com/w3c/vc-data-model/issues/458

[16] https://github.com/w3c/vc-data-model/issues/458

<Zakim> ken, you wanted to say that I can approve the
resolution regarding PR#544

ken: I wanted to apologize to the WG for not keeping up with
that but I can approve the resolution, it was well addressed.

stonematt: Any objections?

RESOLUTION: Issue #458 is addressed by PR #544, which makes
non-normative changes noting when it is and is not appropriate
to use the refresh service. The PR has been approved by
multiple parties and has been merged. Issue #458 should be
closed.

stonematt: No objections, the proposal is resolved.

<manu> [17]https://github.com/w3c/vc-data-model/issues/511

[17] https://github.com/w3c/vc-data-model/issues/511

manu: When you encode a VC in a JWT there is a processing step
that says you use the `sub` field in the JWT and that it should
mention the subject in the credential. A VC can be about
multiple subjects and JWTs do not support multiple subjects.
For example, marriage certificates. The discussion goes on for
a little bit.
... I made a suggestion that notes that JWTs can only currently
support single subjects and implementers should check the JWT
claim registry for multiple subjects. Tony also suggested
something else to reference and it's not a 1:1 mapping to the
problem but Tony would like us to reference it. All we need to
do, I believe, is create a PR for that.

<manu> PROPOSAL: Issue #511 should be addressed by making a
non-normative change to the specification noting that multiple
subjects are not supported by JWTs and implementers should
refer to the JWT registry for future multisubject properties or
the yusef-nested-jwt specification. Issue #511 should be closed
after the PR is merged.

manu: So, whomever cares about that use case for JWTs will go
out to IETF and create that extension it's not up to us. We'll
just add some informative references and let people know this
isn't supported by JWTs at the moment.

<TallTed> +1

<dlongley> +1

<ken> +1

stonematt: Any objections?
... The proposal is resolved.

RESOLUTION: Issue #511 should be addressed by making a
non-normative change to the specification noting that multiple
subjects are not supported by JWTs and implementers should
refer to the JWT registry for future multisubject properties or
the yusef-nested-jwt specification. Issue #511 should be closed
after the PR is merged.

<manu> [18]https://github.com/w3c/vc-data-model/issues/530

[18] https://github.com/w3c/vc-data-model/issues/530

manu: I raised this issue that we need a VC status registry and
more than likely we need other registries and we need a
combined registry, if no one else gets to it I'll take an
action for it.

<manu> PROPOSAL: Issue #530 should be addressed by creating a
Verifiable Credentials Extension Registry in the W3C
Credentials Community Group and requesting that the registry is
adopted as an official W3C CCG Work Item. Issue #530 should be
closed after the W3C CCG accepts the registry as a Work Item.

ken: How does that work, after the CCG says they will take it
on it becomes not our responsibility anymore?

manu: Yes, if you want to add an extension to the registry you
talk to the CCG. It's the same thing as doing, for example, a
DID method spec. You create a spec and ask the CCG for
inclusion into the registry and there's a lightweight process
to add it and then it's there.

ken: That's sufficient.

<TallTed> +1

<ken> +1

<dlongley> +1

<gannan> +1

RESOLUTION: Issue #530 should be addressed by creating a
Verifiable Credentials Extension Registry in the W3C
Credentials Community Group and requesting that the registry is
adopted as an official W3C CCG Work Item. Issue #530 should be
closed after the W3C CCG accepts the registry as a Work Item.

stonematt: No objections, it is resolved.

<manu> [19]https://github.com/w3c/vc-data-model/issues/543

[19] https://github.com/w3c/vc-data-model/issues/543

<manu> PROPOSAL: Issue #543 should be addressed by providing
informative references to detached JWS, LD-Proofs,
LD-Signatures, and the RsaSignature2018 signature suite in
sections 3.4, 3.7, and any other section where it is
appropriate. Issue #543 should be closed after the PR is
merged.

manu: This is actually the same kind of issue that Justin
raised in that other issue, it's to add references to 3.4 and
4.7, anywhere we talk about a full proof and to link to LD
proofs and JWS detached, etc. Just to make non-normative
references to those things if they care about implementing
them.

<dlongley> +1

<TallTed> +1

stonematt: Any objections?
... No objections, it is resolved.

RESOLUTION: Issue #543 should be addressed by providing
informative references to detached JWS, LD-Proofs,
LD-Signatures, and the RsaSignature2018 signature suite in
sections 3.4, 3.7, and any other section where it is
appropriate. Issue #543 should be closed after the PR is
merged.

<manu> [20]https://github.com/w3c/vc-data-model/issues/545

[20] https://github.com/w3c/vc-data-model/issues/545

<brent> +1 to removing the disputes section to implementation
guide

<ken> +1 to what brent said

manu: Let's modify the dispute section, talk about the loose
intention there, the group didn't get to defining it fully but
put it in the implementation guide.

<manu> PROPOSAL: Issue #545 should be addressed by moving the
majority of the Disputes section to the Implementation Guide
and referring to that section from the Data Model
specification. Issue #545 should be closed after the PR is
merged.

<ken> +1

stonematt: Any objections?

TallTed: Does that change the section to non-normative? Let's
be explicit ... "by moving the majority of the at-risk"...

<manu> PROPOSAL: Issue #545 should be addressed by moving the
majority of at risk Disputes section to the Implementation
Guide and referring to that section from the Data Model
specification, and making the Disputes section in the VC Data
Model specification non-normative. Issue #545 should be closed
after the PR is merged.

<TallTed> +1

stonematt: Any objections?

<dlongley> +1

<ken> +1

stonematt: It is resolved.

RESOLUTION: Issue #545 should be addressed by moving the
majority of at risk Disputes section to the Implementation
Guide and referring to that section from the Data Model
specification, and making the Disputes section in the VC Data
Model specification non-normative. Issue #545 should be closed
after the PR is merged.

<manu> [21]https://github.com/w3c/vc-data-model/issues/549

[21] https://github.com/w3c/vc-data-model/issues/549

manu: Yancy raised this issue, we talked about it last week
about how he'd be happy with changing this. The issue here is
that Yancy is saying you have to download the JSON-LD
`@context` and that's problematic. And the assertion is that
"no you don't."
... You literally never have to go out to the Web. If you're
using the credentials context.
... If the other context you're using doesn't say it's cached
forever you may have to get it but it can also say that and
that's an expectation that we will underscore in the best
practices document.
... Wondering if we can flatten all the contexts, there are
three, the VC one, the security v1 and security v2 context.
That requires you to load multiple contexts [from disk, not
required from the Web].
... We would then refer to the context and provide a SHA-256
hash of that context in the spec.

<rhiaro> *and* a human readable copy in the spec appendix
right? because, for humans?

manu: These are non-substantive changes to the specification
and some shuffling.
... Amy is also asking another question we should address in
the spec as well
... First question to Longley is can we flatten everything and
it's fine?

<rhiaro> but if *all* you have is the spec, you can still
implement and hard code or cache your context in an
implementation

<rhiaro> isn't that what appendices are for? :)

manu: Second question is can we put the human readable version
in the spec ... and I say we shouldn't have to is because if
the hash is there you can fetch it and check it.

TallTed: I think including it makes various different kinds of
sense.
... Moving it out is hard to argue. The consistent intro to
this thread is "you literally never have to go out to the Web,
unless, unless, unless"
... In the first iterations, no one is going to use a different
context. Arguments that you never have to go anywhere to get
anything are spurious.

manu: In dev mode you ahve to do that and experiment, In
production you are expected to freeze and we should put that in
production.

<manu> ken: Two questions - one about effect of squashing
@context - does that have any interop problems?

<rhiaro> +1 you have to get it at some point, and maybe this is
a silly premise but if all you have is a printout of the spec
you can still make an implementation compeltely offline and
include it, if the context is in the spec. I also think i'ts
just generally useful for people skimming this stuff

<manu> ken: second, time to cache... is there a mechanism in
production that you're not changing anymore and ok to cache
forever.

manu: Answer to the first question is that squashing doesn't
have any interop issues, zero, no known issues. The time to
cache issue can be done with an HTTP cache -- I believe there
are some that are cache forever.
... In the spec it says you can cache forever.
... There are two ways to do that.

ken: Is it that during development that the expectation that a
context could change but at production it will not.
... Does that apply to the ones the WG has put together and
also others? For specific schemas for those credentials?

manu: That is up to whomever creates those, but we can put it
in the best practices that you should absolutely do that.
... Dev mode it can change, but production it should never
change.

<manu> dlongley: First thing, code that we've written that uses
VC stuff, and verification code... production code pulls all
contexts from disk... people can write their code that way, no
reason to go out to web in production mode.

<manu> dlongley: Can we flatten the context, I think so, we
should do it and see if there are implementation problems and
if not, proceed that way.

<manu> dlongley: We are currently writing implementations
against that context, we can change the context in CR, once we
move on from that, it'll be locked in.

manu: Amy says "If all you have is a print out of the spec you
can implement" ... so Ted and Amy are +1 for putting the
context in the spec directly.

<TallTed> retaining SHA-256 is still good

ken: When you're squashing the contexts -- you're taking some
things that have been standardized or written by another
organization, is it clear that this chunk of the context came
from this original source?

manu: Yes, because we use URLs for everythin.g

<rhiaro> and it isn't *that* big if it's just credentials and
security v1 & v2 isn't it..?

manu: That may not be the full answer to your question. The
context we're using the security v1 and v2 stuff -- DB has been
in control of those contexts until this WG took control.
... When we squash into the vc v1 context it's under the full
control of this group, but we might call out to other
vocabularies.
... We'll review to make sure all that stuff is safe to do. I
did look through all the contexts and it did look doable before
I wrote this proposal up.

TallTed: I think keeping the SHA-256 is good. The file is at
this URL and here's the SHA-256, put that in the appendix.

<stonematt> +1 to keeping SHA-256 reference

<ken> +1 to teds suggestion

<yancy> +1 to SHA-256 ref

<rhiaro> +1 also to the sha256

<manu> PROPOSAL: Issue #549 should be addressed by flattening
all contexts that the specification depends on into
[22]https://www.w3.org/2018/credentials/v1, adding the JSON-LD
Context into an appendix in the spec along with its SHA-256
hash, all of which would be a non-substantive modification.
Issue #549 should be closed after these actions are taken.

[22] https://www.w3.org/2018/credentials/v1,

<TallTed> +1

<dlongley> +1

<deiu> +1

<yancy> +1

<ken> +1

<rhiaro> +1

<bigbluehat> +1 (with necessary cautions)

stonematt: Any objections?

RESOLUTION: Issue #549 should be addressed by flattening all
contexts that the specification depends on into
[23]https://www.w3.org/2018/credentials/v1, adding the JSON-LD
Context into an appendix in the spec along with its SHA-256
hash, all of which would be a non-substantive modification.
Issue #549 should be closed after these actions are taken.

[23] https://www.w3.org/2018/credentials/v1

stonematt: No objections, resolved.

<manu> [24]https://github.com/w3c/vc-data-model/issues/556

[24] https://github.com/w3c/vc-data-model/issues/556

manu: Raised by Ted, about identifiers, asked him to raise a PR
and I reviewed, no substantive changes.

<manu> PROPOSAL: Issue #556 should be addressed by applying the
non-substantive changes requested by the issuer submitter.
Issue #556 should be closed after the PR is merged.

TallTed: As I noted in the PR, there is a neighboring
definition and these two chunks of text overlap a bit and I'm
not sure what the best text is to deal with that.

manu: I'll take a look.

TallTed: It's somewhat clumsy but I don't think there's
disagreement between the two.

manu: I'll see what I can do with my next editorial pass.
... Any disagreements with this proposal?

ken: Are those are normative language changes?

<yancy> I can work on a PR for 549

manu: There are changes to normative language that are
non-substantive, it is a clarification, it won't change
implementations at all.

TallTed: Implementers would change nothing if they understood
the wording correctly in the first place.

ken: Just wanted to deal with CR issues.

manu: If anyone complains they'll have to defend it -- it's
very clear.

stonematt: Any objections?
... No objections, resolved.

RESOLUTION: Issue #556 should be addressed by applying the
non-substantive changes requested by the issuer submitter.
Issue #556 should be closed after the PR is merged.

<manu> [25]https://github.com/w3c/vc-data-model/issues/552

[25] https://github.com/w3c/vc-data-model/issues/552

manu: Thanks, Yancy for volunteering, might need review from
Dave Longley.
... I tried to clarify what I thought this JWT encoding section
meant.

<manu> [26]https://github.com/w3c/vc-data-model/pull/583

[26] https://github.com/w3c/vc-data-model/pull/583

manu: Ted made a PR to address.
... Ted, anything else you want to add?

TallTed: I'm fine with the things I wrote. :)

<manu> PROPOSAL: Issue #552 should be addressed by making a
non-normative clarification related to the various ways the
data model can be encoded using a JWT. Issue #552 should be
closed after the PR is merged.

<yancy> I'm having phone issues. Will run PR by dlongley.

stonematt: Hearing no objections, resolved.

<brent> +1

<ken> +1

RESOLUTION: Issue #552 should be addressed by making a
non-normative clarification related to the various ways the
data model can be encoded using a JWT. Issue #552 should be
closed after the PR is merged.

<ken> +1

<manu> [27]https://github.com/w3c/vc-data-model/issues/557

[27] https://github.com/w3c/vc-data-model/issues/557

manu: This is about the `@context` being an ordered set.
... Making it not an ordered set would argue against the point
of avoiding a JSON-LD processor, so we added PRs about the
order being important.

<manu> PROPOSAL: Issue #557 is addressed by PR #546 which made
non-substantive changes to explain why @context is an ordered
set. PR #546 has been merged and issue #557 should be closed.

<dlongley> +1

<bigbluehat> +1

TallTed: Not an objection per se, there's an open comment on
546.

manu: I'll ask David Chadwick about that.
... For him to open a new issue if needed.

<TallTed> +1

manu: Ted, I'm asking David to open a new issue if that's
really important to him.

TallTed: That's fair.

stonematt: Any objections to the proposal?

RESOLUTION: Issue #557 is addressed by PR #546 which made
non-substantive changes to explain why @context is an ordered
set. PR #546 has been merged and issue #557 should be closed.

stonematt: No objections, proposal is resolved.

manu: Two more to go.

<manu> [28]https://github.com/w3c/vc-data-model/issues/558

[28] https://github.com/w3c/vc-data-model/issues/558

manu: This has to do with processing contexts, also raised by
Tony.
... He's saying that it is recommended that dereferencing the
URIs in the spec and that that text should be removed and that
it can be large security attack vector to dereference documents
on the Web.
... That's not what the text says, it says "only if you
dereference it should you get a machine readable doc", you
don't have to do that and we have additional text now saying
you don't have to go out to the Web for the VC context and
we'll add text to the best practices doc to say not to
dereference in production.

<manu> PROPOSAL: Dereferencing a value in the @context property
should result in a document containing machine-readable
information about the context. Issue #558 should be closed with
no change to the specification.

<dlongley> +1

<ken> no further change to the specification?

<manu> PROPOSAL: Dereferencing a value in the @context property
should result in a document containing machine-readable
information about the context. Non-normative clarification text
should be added to the specification to underscore that
dereferencing machine-readable @contexts is optional. Issue
#558 should be closed with no change to the specification.

<ken> +1

<dlongley> +1

<TallTed> +1

<gannan> +1

stonematt: Any objections?

RESOLUTION: Dereferencing a value in the @context property
should result in a document containing machine-readable
information about the context. Non-normative clarification text
should be added to the specification to underscore that
dereferencing machine-readable @contexts is optional. Issue
#558 should be closed when the PR #564 is merged.

stonematt: No objections, resolved.

<manu> [29]https://github.com/w3c/vc-data-model/issues/559

[29] https://github.com/w3c/vc-data-model/issues/559

manu: This is about verifiable presentations. Tony is saying
VPs are non-normative because there's no interop on VPs. This
is the same thing that has been raised multiple times where his
claim is that you can't create specs with extension points
without defining any extensions and protocols themselves.
... He says we introduce VPs in a non-normative fashion that
everything about them should be non-normative, but that makes
no sense. Often specs introduce concepts in an informative way
because no normative statements are made and then those are
made later.
... We meant to mark the introduction as non-normative and the
part where it talks about the presentation in the data model as
normative.

<manu> PROPOSAL: It is common practice, both at W3C and IETF,
to introduce concepts in a non-normative fashion and then
provide normative statements in the more technical parts of the
specification. Readers are urged to note whether sections are
marked as non-normative and should not assume that other
sections discussing the same concept are non-normative as well.
Issue #559 should be closed with no changes to the
specification.

<TallTed> +1

<dlongley> +1

<ken> +1

<gannan> +1

RESOLUTION: It is common practice, both at W3C and IETF, to
introduce concepts in a non-normative fashion and then provide
normative statements in the more technical parts of the
specification. Readers are urged to note whether sections are
marked as non-normative and should not assume that other
sections discussing the same concept are non-normative as well.
Issue #559 should be closed with no changes to the
specification.

stonematt: Hearing no objections, resolved.

manu: Thank you everyone, that is the last issue I have -- and
the last one I have in the issue tracker as of this morning...
Ted raised another one but that's fine.
... We may have 2-4 CR issues remaining to still process, but
this is the majority of the CR issues. We need to get PRs in
for a lot of these resolutions. I really need help doing that.
If there is a CR issue that has a "Needs PR" tag on it (search
for that) and you feel that you can create a PR for it, please
please help.
... That will make things go much faster. Thank you very much
to Ted for helping with a ton of editorial changes moving
things forward, thanks to Brent, and Ken, and David Chadwick as
well -- if we can more of your help and help from others in the
group then we can very quickly close up to 48 of these issues.

<stonematt> Thanks to all who have been contributing PRs this
month

manu: That's it. Back over to Matt.

Raising Issues for Common Issues

<stonematt>
[30]https://docs.google.com/document/d/1U4Krhjl1dMK294JFp9JuIz_
zmom2zh2CN94Sc0yPpxU/edit

[30] https://docs.google.com/document/d/1U4Krhjl1dMK294JFp9JuIz_zmom2zh2CN94Sc0yPpxU/edit

stonematt: Thank you. I want to come back to the common issue
thread. We will try to come to together around some fundamental
philosophical issues where we see duplication across a variety
of open issues.
... We opened a google doc to draft text for addressing that.
... We will raise 2-3 common issues and Dan Burnett will take
lead on writing that. I won't say don't contribute, but he'll
lead.
... For issues that are essentially just duplicates of those
fundamental issues we'll reference that.
... Keep your eyes peeled for changes to that doc.

Implementation Reports and Questions

stonematt: We want to open the floor -- we have 20 minutes left
on the call today, we can use as much of it as we need to open
the implementation report discussion/.

<Zakim> manu, you wanted to ask about vc-js implementation
report, and updates to test suite... dmitriz ?

manu: Where's the vc-js implementation report and test suite
status?

dmitriz: There's a pending PR to the test suite that adds a
couple more changes that we put in for CR. Some more fields
have become required since before CR.
... That updates the test suite with those changes and there's
an implementation report from DB's vc-js library.
... Look early and often for changes, we should be good on our
end.
... In response to Brent's question a couple days ago, I left
instructions on how to hook up your own library to the test
suite.

manu: There's a report, but we haven't run the processor to
update the page yet?

dmitriz: Right, I probably misunderstood the directions, I
thought the report generates and processes in one command.

manu: I don't remember, we should get it so that everyone can
see what a successful test report looks like.

dmitriz: Ok.

stonematt: Do we have something along the lines of a tutorial
or recipe guide for how to do all that as well?

dmitriz: It's in an issue at the moment and we can cut and
paste that into a standalone document.

stonematt: Can we have that in a README?

<manu> We should put it here ---
[31]https://w3c.github.io/vc-test-suite/

[31] https://w3c.github.io/vc-test-suite/

dmitriz: It's a little informal at the moment, I would like
feedback from Brent and other implementers as to if it made
sense.

manu: If you put that link from IRC into the browser it tells
you how to run the test suite and we should put that HOWTO from
the issue in there.

<dmitriz> [32]https://github.com/w3c/vc-test-suite/issues/14

[32] https://github.com/w3c/vc-test-suite/issues/14

dmitriz: That's fine.

<ken> Putting the instructions in the doc would be helpful.

manu: We may also want to point to the issue with vc-js verify.

dmitriz: The comment in the issue goes into that.

brent: I haven't had a chance to try that out yet, it helps me
having a document we can update as more questions come in.

<stonematt> +1 to a README or "HOWTO"

brent: +1 to moving the comments from an issue to a document.

<Zakim> manu, you wanted to note README

<manu> [33]https://w3c.github.io/vc-test-suite/

[33] https://w3c.github.io/vc-test-suite/

manu: +1 to a strong preference for putting everything in the
README.
... My hope is that the URL I put in IRC is the place people
can go to find out what implementations exist that are
conformant to the specification as well as how to write your
own, hook up to the test suite, etc.
... One stop shop for all of that, current implementations,
what they support, what they don't, how you can write your own.
Having more than one place for that is confusion, so just one
place, that README would be good.

stonematt: That makes sense, right marching orders for Dmitri
or whomever to make updates.
... Any other questions about test suite or implementation
reports today?

none

stonematt: That covers our agenda, we had a placeholder for
scheduling ad hoc discussion if necessary from the issue
lightning round, I didn't hear any. If anyone needs discussion
this week, raise your hand now, otherwise we're done for the
day.
... Any other business?
... Ok, 10 minutes back. Thanks for a great call, got through a
ton of stuff and really appreciate everyone's attention and
focus on the spec in the last few weeks and we've made a ton of
fine tuning contributions and it's coming together in a nice
way, good bye!

<stonematt> good bye everyone!

Summary of Action Items

Summary of Resolutions

1. [34]The WG believes that the type system described in the
specification does not require a JSON-LD processor to be
used and the concerns raised in issue #484 have been
demonstrated to be expressible in JWTs using the VC Data
Model in a way that is both conformant with JWTs as well as
other expression mechanisms. No technical examples have
been provided that demonstrate that the type system used
for the Verifiable Credentials Data Model either 1)
requires a
2. [35]The WG has considered the proposals raised in Issue
#484 and continues to support both JWTs and JSON-LD in the
specification, continues to support the use of @context as
it exists in the specification today, supports any valid
JWT claim expressed in a JWT-based serialization, and
supports the use of JWS with the specification. The WG has
discovered no technical reason that JWE cannot also be used
to encrypt data expressed in the specification. Issue
3. [36]Issue #470 should be addressed by making a set of
non-normative changes to the specification that adds a
simple note after each RsaSignature2018 example with an
informative reference to that spec and that mentions it
used a JWS detached signature with an informative reference
to the JWS spec. Issue #470 should be closed after the PR
is merged.
4. [37]Issue #474 should be addressed by making a set of
non-normative changes to the specification that clarifies
the use of @context, the differences between it and the
credentialSchema property, with appropriate references to
more detailed explanations in the specification and other
specifications. Issue #474 should be closed after the PR is
merged.
5. [38]Issue #458 is addressed by PR #544, which makes
non-normative changes noting when it is and is not
appropriate to use the refresh service. The PR has been
approved by multiple parties and has been merged. Issue
#458 should be closed.
6. [39]Issue #511 should be addressed by making a
non-normative change to the specification noting that
multiple subjects are not supported by JWTs and
implementers should refer to the JWT registry for future
multisubject properties or the yusef-nested-jwt
specification. Issue #511 should be closed after the PR is
merged.
7. [40]Issue #530 should be addressed by creating a Verifiable
Credentials Extension Registry in the W3C Credentials
Community Group and requesting that the registry is adopted
as an official W3C CCG Work Item. Issue #530 should be
closed after the W3C CCG accepts the registry as a Work
Item.
8. [41]Issue #543 should be addressed by providing informative
references to detached JWS, LD-Proofs, LD-Signatures, and
the RsaSignature2018 signature suite in sections 3.4, 3.7,
and any other section where it is appropriate. Issue #543
should be closed after the PR is merged.
9. [42]Issue #545 should be addressed by moving the majority
of at risk Disputes section to the Implementation Guide and
referring to that section from the Data Model
specification, and making the Disputes section in the VC
Data Model specification non-normative. Issue #545 should
be closed after the PR is merged.
10. [43]Issue #549 should be addressed by flattening all
contexts that the specification depends on into
https://www.w3.org/2018/credentials/v1, adding the JSON-LD
Context into an appendix in the spec along with its SHA-256
hash, all of which would be a non-substantive modification.
Issue #549 should be closed after these actions are taken.
11. [44]Issue #556 should be addressed by applying the
non-substantive changes requested by the issuer submitter.
Issue #556 should be closed after the PR is merged.
12. [45]Issue #552 should be addressed by making a
non-normative clarification related to the various ways the
data model can be encoded using a JWT. Issue #552 should be
closed after the PR is merged.
13. [46]Issue #557 is addressed by PR #546 which made
non-substantive changes to explain why @context is an
ordered set. PR #546 has been merged and issue #557 should
be closed.
14. [47]Dereferencing a value in the @context property should
result in a document containing machine-readable
information about the context. Non-normative clarification
text should be added to the specification to underscore
that dereferencing machine-readable @contexts is optional.
Issue #558 should be closed when the PR #564 is merged.
15. [48]It is common practice, both at W3C and IETF, to
introduce concepts in a non-normative fashion and then
provide normative statements in the more technical parts of
the specification. Readers are urged to note whether
sections are marked as non-normative and should not assume
that other sections discussing the same concept are
non-normative as well. Issue #559 should be closed with no
changes to the specification.

[End of minutes]
__________________________________________________________

Minutes manually created (not a transcript), formatted by
David Booth's [49]scribe.perl version 1.154 ([50]CVS log)
$Date: 2019/05/01 08:46:12 $

[49] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[50] http://dev.w3.org/cvsweb/2002/scribe/

Received on Wednesday, 1 May 2019 08:48:39 UTC