<burn> Chair: Dan_Burnett, Matt_Stone
<manu> scribenick: DavidC
<scribe> Agenda: PRs
<manu> https://github.com/w3c/vc-data-model/pulls
<manu> https://github.com/w3c/vc-data-model/pull/577
manu: This PR is stuck until we get comments from other people
Please can people review this PR and comment on it
TallTed asks if anyone else has looked at this?
No-one appears to except Manu
<manu> DavidC: We are getting in too deep with this, other than order is approximate. We don't wnat to give a specific menu for the order, or specific flow diagram, I don't think we need to be specific here.
<burn> DavidC: we are going too deep with this. All we need is the approx. order. We don't want a detailed order here.
Ken will do a review
<manu> TallTed: There are other sections that prevent things from happening, that's specific, if this is not important, then none should be there.
<manu> https://github.com/w3c/vc-data-model/pull/587
@context will be added to the Appendix.
<manu> https://github.com/w3c/vc-data-model/pull/597
manu: This announces the end of the CR period
burn: The end of the comment
period means that external reviews may not be processed
... This is so that a specification can end (otherwise people
may comment on it for ever)
<manu> https://github.com/w3c/vc-data-model/pull/597
burn: Group members are not included in this, as they are working hard to make sure the spec is finished
scribenick: manu
DavidC: Yes, I was asking you to add text to my text.
... If people want to know exactly about the @context, then they can go read another spec... I think we need to do an intro.
... There needs to be a minimum, there is some minimum irreducible features... that's what I'm looking for.
<dmitriz> "how to extend a VC" / create your own context — that sounds like it needs a section (or its own guide) in the Implementation Guide
<burn> Note that long conversation between manu and davidc was not scribed
scribenick: burn
manu: using VCs does not require JSON-LD knowledge, but extending VCs requires a deep knowledge of JSON-LD
davidc: we need to know what each field is for, and we will have to add fields.
... reasonably happy with schema def, but not schema.org because it doesn't say what must/may be present.
<brent> the minimum irreducible set of requirements for context for JSON and JSON-LD is that the context must be present
davidc: context is a big vague hole.
manu: let's work on this in the PR
scribenick: DavidC
PR #601 is adding missing presentation types
<manu> https://github.com/w3c/vc-data-model/issues/537
Manu: this says to use JSON-LD
1.0 and not 1.1
... we need to get 1.1 to CR so that it can be referenced
... but currently we will have to reference 1.0
<manu> PROPOSAL: Issue #537 should be addressed by referencing JSON-LD 1.1 instead of JSON-LD 1.0. This is a non-substantive change since the Verifiable Credentials Data Model specification included JSON-LD 1.1 features inline for JSON-LD based processors and thus implementers would not have to change their implementations as a result of the updated reference. Issue #537 should be closed after the PR is merged.
Manu: we use the protected
mechanism to stop terms being redefined in JSON-LD
... instead we require @context values to be placed in
order
<TallTed> +1
<ken> +1
<burn> +1
<deiu> +1
RESOLUTION: Issue #537 should be addressed by referencing JSON-LD 1.1 instead of JSON-LD 1.0. This is a non-substantive change since the Verifiable Credentials Data Model specification included JSON-LD 1.1 features inline for JSON-LD based processors and thus implementers would not have to change their implementations as a result of the updated reference. Issue #537 should be closed after the PR is merged.
<brent> burn: I see no objections
<manu> https://github.com/w3c/vc-data-model/issues/551
<manu> PROPOSAL: Issue #551 is addressed by PR #563 which makes non-normative changes to fix the missing @context values in a number of the examples in the appendix. Issue #551 should be closed.
<ken> +1
<TallTed> +1
<DavidC> +1
RESOLUTION: Issue #551 is addressed by PR #563 which makes non-normative changes to fix the missing @context values in a number of the examples in the appendix. Issue #551 should be closed.
<brent> burn: no objections
<brent> manu: there are 17 issues we need to address
<manu> https://github.com/w3c/vc-data-model/issues/222
<brent> manu: what we're looking for is any objections with the proposed way forward
Coordinate with PING
Manu: chairs are continuing to do this
<manu> https://github.com/w3c/vc-data-model/issues/436
PR #436 language support
Manu: JSON processors cannot
support this
... this conversion will continue with the I14N team
<manu> https://github.com/w3c/vc-data-model/issues/470
<manu> https://github.com/w3c/vc-data-model/issues/474
Manu: a 7 day close will be added to it
two PRs have been issued for this
<manu> https://github.com/w3c/vc-data-model/issues/479
Manu: this may require a
significant amount of work to address
... instead we should clarify ToUs so that issue can be
resolved
Burn: perhaps we should only add 7 day close to items that already have a PR issued for them
<brent> do we need a resolution for 479?
<manu> https://github.com/w3c/vc-data-model/issues/480
Manu: this is problematic because
it is a substantive change if it is to be fully addressed
... so conversation will continue in the issue.
... is anyone going to raise a formal objection is this is not
resolved?
<manu> PROPOSAL: The Working Group has discussed issue #480 and is not willing to make a substantive change to the specification that would trigger another Candidate Recommendation phase. The Working Group is interested in exploring non-normative resolutions to the issue.
<manu> DavidC: At what time do we enter another CR? We should do that if possible.
Burn: we have no time to issue a new CR and get the spec finished by end of Sept
<manu> DavidC: What's the process for 1.1?
<manu> TallTed: The process is another WG
Burn: we have a defer category to push items to another WG for V1.1
TallTed: this is a perennial issue
Burn: there are politics involved
as well as technical issues
... at some point we have to say, go with what we have now,
rather than risk getting nothing
TallTed: One constraint is that all things in this spec have to continue to work with any new spec
<Zakim> manu, you wanted to mention "a loose plan"
Manu: 1.1 spec will go back to
the CCG to continue being worked on
... implementations will continue to work on getting VCs to
work
DavidC: what is the status of the
implementation guide?
... can this be used to advance the standard
Manu: Yes it can along with the test suite
<manu> PROPOSAL: The Working Group has discussed issue #480 and is not willing to make a substantive change to the specification that would trigger another Candidate Recommendation phase. The Working Group is interested in exploring non-normative resolutions to the issue. The WG would like to defer the issue so it can be considered when work continues beyond VC 1.0.
<burn> +1
<TallTed> +1
<DavidC> +1
<deiu> +1
<brent> +1
RESOLUTION: The Working Group has discussed issue #480 and is not willing to make a substantive change to the specification that would trigger another Candidate Recommendation phase. The Working Group is interested in exploring non-normative resolutions to the issue. The WG would like to defer the issue so it can be considered when work continues beyond VC 1.0.
<manu> https://github.com/w3c/vc-data-model/issues/518
this is about multiple subjects with JWT
Manu: we will add an example to solve this
<manu> https://github.com/w3c/vc-data-model/issues/526
<manu> https://github.com/w3c/vc-data-model/issues/584
Manu: we can suggest to implementors that these names may change in the future
<manu> DavidC: The point I raised is that the issuance date is not the important date, it's when it's valid from... it's not just a change of name, but a change of semantics.
<manu> DavidC: We could add a second field "validFrom"... optional to use, then validFrom == issuanceDate.
<manu> TallTed: The trouble w/ that is treating issuance as valid from is what's going to happen in most cases. A conformant processor will treat issuanceDate as validFrom whether or not it's present.
<manu> ken: It seems confusing to put in an alias and have it pass the test suite. Don't understand how that's going to play out.
<manu> TallTed: issuance date is not the same as valid from... doesn't say anything wrt. validity.
<Zakim> manu, you wanted to note that the intent was that it was "validFrom"
<Zakim> burn, you wanted to explain 'reserved word' as alternative and to mention also that clarifications are okay
TallTed: are we going to add a new field in the future called validFrom?
DavidC: we only need to change the semantics of the current definition and add a note that this date can be in the future
<manu> https://github.com/w3c/vc-data-model/issues/585
Manu: where do JSON developers
find the order of @context values
... they have to search for it
<manu> DavidC: There are two issues 1) Where do you find the human readable text? Can you have description in the @context, yes? We could say there is a way to get a human readable bit.
<manu> manu: Yes, you can put a pointer in there...
<manu> DavidC: Ok, then I'm happy as long as you can find it via a comment.
<manu> https://github.com/w3c/vc-data-model/issues/586
Manu: it we were to add a new JSON property, say description, then this will have to be run past the JSON_LD group to OK it
<brent> DavidC: when I looked at the text, I don't know how to take VPs into JWTs
<manu> DavidC: When I looked at the text, implementing, I don't know how to do it... JWT tells us how to turn a VC to JWT... take properties out, make them into fields... no equivalent text on how to turn VP to JWT.
<brent> ... the only examples have JSON-LD proofs
<manu> manu: We could put all this in the implementation guide?
Manu: we cannot add normative statements to the text so this will have to go in the implementors guid
DavidC: can we also mark it as deferred?
TallTed: this is why we need another CR
<manu> https://github.com/w3c/vc-data-model/issues/589
Point to an out of date internet draft
IDs are only valid for 6 months
So we should never reference IDs
RFCs are OK as they are long lived
Manu: we can point to expired ID or to JSON schema web site
DavidC: I prefer JSON schema web site
<manu> https://datatracker.ietf.org/doc/draft-zyp-json-schema/
<jonathan_holt> https://datatracker.ietf.org/doc/draft-wright-json-schema/
<manu> We should use this URL: https://datatracker.ietf.org/doc/draft-handrews-json-schema/
<DavidC> +1
<manu> https://github.com/w3c/vc-data-model/issues/596
Holder should be added to implementation guide
<manu> https://github.com/w3c/vc-test-suite/pull/15
<manu> First vc.js implementation report is in! https://w3c.github.io/vc-test-suite/implementations/#conformance-testing-results
Manu: Yancy is having difficulty with putting VCs in the playground
<yancy> https://www.w3.org/2018/credentials/examples/v1
<manu> < content-type: application/octet-stream
Manu: there is an issue with the
way the @context file is served.
... it should be application json-ld???
jonathan_holt: is there a plan to create a JSON schema file
Manu: not for the test suite
jonathan_holt I support you in this
Manu: should it be part of the
test suite or the implementation guide?
... we would welcome a PR for the implementation guide
<DavidC> +1
Yancy: what is the possibility of modifying the test suite so that we dont have any external content
dmitriz: we could make it standalone content
Yancy: could we have @context in-line
dmitriz: we need to provide more documentation about this as all implementors will hit it
<Zakim> kaz, you wanted to mention it sounds like we need to modify .htaccess file
<manu> Two things need to be done: Serve https://www.w3.org/2018/credentials/examples/v1 using CORS and make sure it's served as application/ld+json
DavidC: we should ensure that
must and may is indicated for properties
... using the Required property
[adjourned]