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> 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> 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

<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.

<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> 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> 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> https://github.com/w3c/vc-data-model/issues/474

<manu> 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> https://github.com/w3c/vc-data-model/issues/458

<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.

<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> 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> 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> 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> 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> 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 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.

<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 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.

stonematt: No objections, resolved.

<manu> 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> 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> 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> 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> 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.

<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 when the PR #564 is merged.

<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> 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> 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 --- 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> 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> 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!