Describe plan for the call

<brent> scribenick: brent

burn: first PRs, then closing issues, then test suite, then implementation topics
... anything else that should be added?

https://github.com/w3c/vc-data-model/pulls

PRs

PR announcements

manu: good news, thanks to everyone who puts in PRs. Brent, Ken, David, Ted.

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

manu: 641 is first up.

<Justin_R> I would call in but I don't have the new meeting info.

manu: internationalization has been re-written 5 times now

<Justin_R> So if anyone can help with that, please DM me

manu: many other groups are chiming in, separate calls are happening
... we believe we have a proposal. It may not actually be a needed solution.
... we are getting mixed signals
... we may end up pointing to the string meta specification
... the current PR is where the discussion is now..
... if it changes again it will simply point to string meta.
... if no progress is made, it will be revised.

ken: ripped out all the french language examples?

manu: yes, because we did that wrong
... no markup in the data, it is a attack vector
... instead we will write an example that shows how to use a language tag.
... we will put some language examples back, but can't do directionality.

ken: should we make corresponding changes to the test suite?

manu: yes
... unfortunately now we are the "stuckee" for language direction on the internet.

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

manu: 646, validFrom and validUntil. Looking for re-review after changes.
... the problem is that issuanceDate is different from validFrom and maps to different things in JWT.
... so mapping it to something different may be a normative change.
... this PR doesn't make changes to the JWT section, it only says that these terms are going to be used in the future.
... take a look at 646

dlongley: Ted was recommending adding non-normative text to the JWT section.
... add validFrom in the future and have it map to something else.
... validFrom and issuanceDate are different.

manu: example is digital coupons

<Zakim> burn, you wanted to ask about validFrom

burn: is there a situation where someone would want to use validFrom as a date before it was issued?

manu: potentially

burn: even though it was issued when I was 16, it was valid from when I was born

dlongley: yes, this PR brings up the fact that they have different meaning.
... if you only had issuanceDate, then the credential can't be valid before that date.

manu: please comment on the PR

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

manu: 652 is up next
... Tony said JWS is a proof mechanism, JWT needs to be there as well. It has gone back and forth.
... some things are standardized, some are not. Asked for re-review from Tony.
... expect he will want a stronger statement about what is a standard or not.
... giving that treatment for everything in the text would add alot of stuff.
... suggestion is to go with the modified text.
... would like to hear is there are objections?
... not hearing any, do we need a resolution?

burn: it would be good to do that. that can be dropped in to say what the WG has confirmed.

<manu> PROPOSAL: The Working Group has confirmed that calling out the phase of standardization that any particular specification is in is not necessary as implementers can determine that information from the heading information in each specification as well as perusing the normative and non-normative reference section.

manu: any objections?

ken: it doesn't actually reference which one we're talking about.

manu: it shouldn't matter, this is general

RESOLUTION: The Working Group has confirmed that calling out the phase of standardization that any particular specification is in is not necessary as implementers can determine that information from the heading information in each specification as well as perusing the normative and non-normative reference section.

burn: no objections

manu: please review the PR

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

manu: Ted did a new PR, 663
... this is editorial

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

<manu> scribe: manu

brent: PR 658 was in response to issue 653, and issues 653 came up during a WG conversation... basically, the question was "how many types must a presentation have?"
... Some of the language in the next makes it suggest that you have to have at least two... my initial reading of the text was opposed to others reading of the text...
... two sides seem to be -- type needs to be explicit and always mentioned in the type field, or type out to be implicit and should be allowed, properties not described by any type anywhere, then they need to be undrestood by verifier, or rejected because they are not understood, but should be allowed by the spec.
... That's my understanding of the two sides of the argument, we need the group to weight in on what should go into the spec.

<inserted> scribenick: brent

manu: David is arguing from a strong typing argument. Try to list a type, some are mandatory. The compromise was that some must be mandatory.
... in presentation, it doesn't make sense to require two types.
... it can be done, but I feel it goes too far to require it.
... I know David wants that, but I don't think it should.
... we were fine with duck-typing, nothing breaks if you don't specify the type.
... the compromise was to help JSON developers.
... linked data community has never done.

<manu> brent: My $0.02 is in the PR, I think that's what it should say.

manu: is anyone supporting David's positional at this point?
... he isn't on the call, but no one is supporting the opinion that type is mandatory.

burn: I want that in the minutes, there is no support for David's opinion

ken: Is removal of sub-typing applicable to only the presentation, or to both?

manu: we can't change anything normative.
... we say it must be associated with a more narrow type.

dlongley: this debate has been about defining "be associated with"
... do those need to be explicit?
... This PR clarifies that.

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

manu: I want a resolution on this, everybody please go to the link and read it.
... I think the spec text is fine, minus the added termsOfUsePResentation

brent: I can remove that.

manu: would anyone object to David's idea?
... digital bazaar objects

oliver: I also object

ken: As do I

brent: me too

manu: any other strong feelings?

<manu> PROPOSAL: Merge PR 658 as it reflects the consensus of the Working Group. Specifically, more organizations would object to more stringent type requirements than what exists in PR 658.

manu: any objections?

burn: no objections

RESOLUTION: Merge PR 658 as it reflects the consensus of the Working Group. Specifically, more organizations would object to more stringent type requirements than what exists in PR 658.

manu: I'll merge that as soon as Brent makes the minor change

burn: that resolution only applies after a change has been made.

We have so many issues

manu: the good news, we have a pretty good handle on them
... we are getting PRs.
... I think we're done with the spec. we need folks to do a read of the whole thing.
... need to get the internationalization in. The rest of them feel addressable.
... hopefully by the end of this month we will be ready.
... other thing is, some may be able to mark them as 7 day close.

burn: I will go through and check them all

oliver: we still don't have JWT test cases. uPort will also provide an implementation
... question about timeline for CR and features at risk.

manu: in general, don't worry. We will wait.
... but september is the end point
... things need to happen asap

burn: the main thing. PR is the last thing. Tony has said he will raise objections.
... I will not be surprised if he raises objections that require discussion, and that takes time.
... need to aim for PR at the end of the month. try to get implementations in.
... as far as comment period. CR has expired. That is comments from outside. the WG still addresses internal issues.
... comments from you that are implementation related will be addressed.

manu: issue processing

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

manu: issue 621
... Oliver,I think you have a good handle on this. can you summarize where we are?

oliver: the conclusion is we should provide language that describes which attributes could have multiple types, or which could change from objects to arrays.
... my team would like an exhaustive list.

<Justin_R> +1 to the request

manu: are you saying, you would like a list of every attribute in the spec, or for everythin?

oliver: in the spec.

manu: I think we state in each attribute if it can be a single value or an array.
... there are some examples of singletons.
... I think that information is implicit in the spec. We could call it out in the implementation guide. or in the spec.

oliver: I would like something in the spec. I think we can have non-normative statements around that.

Justin_R: It is imperative that the data elements specify their arity. We need that in the data model.
... if it was always the intent that either type has always been allowed for certain properties, that should be clarified.

<dmitriz> +1

+1

<ken> +1

<dlongley> +1 i think it's just clarification text

manu: we'll add spec text
... where should this be?

dmitriz: I think it is suffienct to say, everything may be multiple, except these few singletons

manu: any objections?

Justin_R: I think since this was always the intent, we should add clarifying normative language.

<manu> https://github.com/w3c/vc-data-model/issues/621#issuecomment-500877312

manu: added that to the issue.

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

manu: next is 642, protocol buffer support
... why didn't you do protocol buffers? The @ character isn't supported in protobufs
... from and to different serializations can be done.
... suggestion is to change nothing.
... we can change the text to mention protocol buffers.

<Zakim> Justin_R, you wanted to discuss serialization

manu: commenter hasn't responded. I think the spec is clear already. If someone wants to add it, then add protocol buffer support and mention mappings will need to be made.

Justin_R: serialization isn't really handled in the spec. this same approach should apply to protocol buffers.
... to use any serialization, you need another spec to say how to do that in either direction.
... this spec is the wrong place, but we need a family of specs that very clearly state how to do that.

manu: are you saying, let's add language that points out that need for more specs?

Justin_R: not suggesting we add that, it is already there.

manu: you're saying no change to the spec

<manu> https://w3c.github.io/vc-data-model/#syntaxes

Justin_R: I'm saying our response to the issue needs to be "any necessary transforms to support protocol buffers requires a different spec."

<Justin_R> Current text:

<Justin_R> A conforming document is any concrete expression of the data model that complies with the normative statements in this specification. Specifically, all relevant normative statements in Sections § 4. Basic Concepts, § 5. Advanced Concepts, and § 6. Syntaxes of this document MUST be enforced. A serialization format for the conforming document MUST be deterministic, bi-directional, and lossless as described in § 6. Syntaxes. The conforming document MAY [CUT]

<Zakim> burn, you wanted to say we have not defined how extension to new syntaxes should occur

burn: Justin is right. we didn't say how extensions should occur. We have provided examples.
... syntaxes have been described, but not serializations
... perhaps distracting now. Response to issue should be: our expectation is that a new syntax should be written that contains the serialization rules.

<manu> PROPOSAL: The Working Group has discussed issue 642 and decided to make no changes to the specification. A response to the issue submitter should instruct them to create a separate serialization specification that maps the data model to and from the serialization that they desire.

manu: any objections?

<Justin_R> wfm

RESOLUTION: The Working Group has discussed issue 642 and decided to make no changes to the specification. A response to the issue submitter should instruct them to create a separate serialization specification that maps the data model to and from the serialization that they desire.

burn: I think that's fine, but may lead to the question: what do I do with the resulting spec?
... no objections

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

manu: next up 653. We just did a resolution for that with PR 658
... don't need to discuss 653

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

manu: 654, Ken you raised the issue and it was fixed with a merged PR.

ken: please close it.

<manu> PROPOSAL: Issue #654 is addressed via PR #655. The PR has been merged, close the issue after a 7 day wait period.

manu: any objections?

burn: I don't think we need a 7 day close

It is an internal issue

<manu> PROPOSAL: Issue #654 is addressed via PR #655. The PR has been merged, close the issue immediately (no 7 day close).

manu: any objections?

RESOLUTION: Issue #654 is addressed via PR #655. The PR has been merged, close the issue immediately (no 7 day close).

burn: no objections

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

<manu> brent: He had some questions about credential subject, some other questions, I responded. I didn't say I don't think we need to make changes, but we may want to do that.

burn: 659, support ticket as issue

<manu> PROPOSAL: Issue #659 has not resulted in any suggested changes to the specification, the issue should be closed after a 7 day wait period. Notify the issue submitter that we're happy to continue the discussion with them in the issue or the mailing list after the issue has been closed.

manu: working on re-wording the proposal

<manu> PROPOSAL: Issue #659 has not and does not appear likely to result in any suggested changes, the issue should be closed after a 7 day wait period. Notify the issue submitter that questions should be directed to the mailing list for further discussion.

burn: my suggestion, with the last sentence. we recommend to move the discussion to the mailing list. and then do that.

<manu> PROPOSAL: Issue #659 has not and does not appear likely to result in any suggested changes, the issue should be closed after a 7 day wait period. Notify the issue submitter that we are moving the discussion to the public-vc@w3.org mailing list.

burn: copy something from the issue into an email.

manu: any objections?

burn: none

RESOLUTION: Issue #659 has not and does not appear likely to result in any suggested changes, the issue should be closed after a 7 day wait period. Notify the issue submitter that we are moving the discussion to the public-vc@w3.org mailing list.

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

manu: 662
... same kind of issue

<manu> PROPOSAL: Issue #662 has not and does not appear likely to result in any suggested changes to specification text, the issue should be closed after a 7 day wait period. Notify the issue submitter that we are moving the discussion to the public-vc@w3.org mailing list.

burn: no objections

RESOLUTION: Issue #662 has not and does not appear likely to result in any suggested changes to specification text, the issue should be closed after a 7 day wait period. Notify the issue submitter that we are moving the discussion to the public-vc@w3.org mailing list.

manu: and that is all the issues
... maybe a PR or two outstanding.
... it would really help it a full reading of the spec could be done. put in PRs for editorial fixes.
... you may catch something weird with a full read-through

burn: let's move to test suite.
... actually, I would like to ask Justin if he could take over as scribe

Justin_R: can't today

ken: I can do it

burn: but will you be talking?

<bigbluehat> scribenick: bigbluehat

<brent> ... thanks Benjamin

kaz: we're trying to identify some callers

Test Suite Issues and Discussion

burn: they are...but not in WebEx...

<burn> https://github.com/w3c/vc-test-suite/issues

burn: did you update them kaz?

kaz: yes.

burn: thanks. anyway, test suite
... dmitriz, could you take us through outstanding issues on the test suite?

dmitriz: we'll go through the PRs first in reverse chronological order

<gannan> can we get a link?

<burn> https://github.com/w3c/vc-test-suite/pulls

<dmitriz> https://github.com/w3c/vc-test-suite/pull/36

<dmitriz> (propose we merge)

<dmitriz> https://github.com/w3c/vc-test-suite/pull/42 and https://github.com/w3c/vc-test-suite/pull/46

dmitriz: these are two exciting test results
... and now manu's cheering in IRC :)

burn: let's do these one at a time.

dmitriz: k. first, 42 the sovrin implementation

burn: can't see why there'd be objections

dmitriz: k. I'll click the button
... next is 46 for evernym
... and...no objections, so merging
... and while we're here, PR 36

burn: any objections to 36, the test suite sequence diagram?
... there haven't been since this was submitted

manu: so, we'll be able to see this once the merge is complete, but I'm curious what features weren't implemented

<dmitriz> that was Ken

<dmitriz> and now Brent

brent: so, evernym's implementation is completely separate, so we might be able to convince each other to do these unimplemented features
... there were also JWT tests which weren't implemented...even if oliver does
... these aren't objections to the feature, just a lack of time

burn: not sure where we are, oliver's on the queue

oliver: yeah, I'm curious. Do sovrin and evernym think its possible to use JWT with these secret keys in general?

brent: at first glance, I don't think so.
... I believe we want to support receiving JWTs
... if they (IRMA) have a way to do it, I don't see why we wouldn't

ken: we may have a ZKP style signature that we both read and write
... and we'd heartily support bringing in JWT text-style signatures that we can both read and write
... but we're not at that stage yet, but would love contributors to help make that happen

burn: k. no other questions? back to you dmitriz

dmitriz: switching to the issue list, we have 2 new issues that are unassigned

<dmitriz> https://github.com/w3c/vc-test-suite/issues/45

dmitriz: one is issue 45 by brent
... I thought it was a companion to a test report
... but it looks like an error from brent
... what version of node are you using?

brent: version 8.10.0

dmitriz: and then we have issue 44

<dmitriz> https://github.com/w3c/vc-test-suite/issues/44

dmitriz: issue about ZKP VC's
... question by yancy
... brent gives a response, so yancy do you have any further questions?

yancy: I've not yet looked into the response
... my main question would be that looking to the ZKP test suite
... that credential schema must exist or else its not valid
... but some of the earlier tests don't require schema if they're not using ZKPs

<Zakim> manu, you wanted to note how

yancy: so I'm trying to figure out how the verifier can make the distinction between the ZKP one and a non-ZKP one

manu: sorry, my audio crashed part way through, so apologies if I've missed the question
... you essentially just look at the type

yancy: so in the proof section
... if the proof type is ZKP, so like example 22
... so that's supposed to mean it's a ZKP style proof?

manu: yes, exactly. My examples don't line up with yours
... so, yes, like that example, part of validating that proof is checking for that schema

yancy: any other types like this?

<dlongley> the expectation is that your verifier understands proof types -- if you don't, you reject the VC.

manu: clearly evernym and sovrin will need to jump in, but that's the only one right now
... that might change, but that's how it is right now
... with LD signatures, you just check the type of the proof and the schema to verfiy
... yes, you will need to specify a specification that explains how to normalize the data
... it will look like RSA 2016 or those other specs
... if it's based on the LD signature stuff
... but if it's based on JWTs, it'll be based on something like those
... the whole purpose was to allow these other cryptographic methods to exist
... and those can bloom on a totally different timeline than the VC spec does

jonathan_holt: so, I've been working on the JSON Schema
... so the credential attribute is on the body of the document
... are you requiring a credential schema on the proof object?

dmitriz: can I reply?

burn: yes

dmitriz: good question, this is an example on a previous call
... as far as I know, there isn't a way to do a conditional check
... that'll need to be done in code
... if the type is ZKP, then this field is required
... so if you're using JSON Schema, then you'll have to set it as optional

jonathan_holt: the newest version does, but I'm still learning how to write those to support this

ken: so, like manu said, we should be ready for additional ZKP styles as time goes forward

burn: so, would it be beyond the pale of what we're allowed to do
... to add a clarifying statement, that it is recommended to add a ZKP verifiable credential type?
... I understand that everyone's going to do their own thing
... but would it be inappropriate in our spec to have an additional more narrow credential type to specificy that it's a ZKP credential?
... dmitriz thoughts?

<Zakim> manu, you wanted to note that JSON Schema uses this field differently from how ZKPs do...

dmitriz: well, I think it's more a question for you burn because I'm not sure about CR breakage

manu: not sure if my opinion's well formed, but you can always do that
... you can always add whatever new type to credentials , etc, and that can trigger other code
... so there will be other specs that say, if you're encoding a ZKP credential do it this way
... but I'd recommend against that, because there's unique stuff in the proof that enables the ZKP verification of this

brent: so that schema point is the additional bit needed for verification
... so if there's a way at the credential level, to let you know you're going to need that schema in the proof

manu: I don't really think you need to do that for it to work well or cleanly
... but maybe we should discuss this offline

<dlongley> there's no order to JSON keys... not sure what "before you jump into the proof section" means

manu: I don't think you would need to fetch the credential schema before you were in the process of doing the ZKP validation

<yancy> +1 for not needing credentialSchema for a zkp

manu: I really feel like the type in the proof gives you what you need to determine the algorithm

jonathan_holt: just to clarify, the JSON Schema really validate the format, not the meaning
... I can validate that the attributes and values are there
... the meaning that this is now a ZKP credential, is more embedded in the structure

manu: correct, semantics is beyond what JSON Schema was designed to do

jonathan_holt: but conditional checks can be done, like if this is a state, check for postal code

manu: correct

yancy: yeah, I'm wondering if it makes sense to somehow
... I guess I'm not convinced that a ZKP requires credential schema
... I guess I was wondering if, for a Anoncred v1
... if it really requires credentialSchema
... that there might be other ZKP implementations that don't require credentialSchema

ken: in order to do the proofs, the ordering of the data is crtical
... there may be a way to do it without that, but right now that's how its done

<manu> +1 to Ken for depending on proof.type declaration.

<dlongley> +1

ken: I'd prefer to use the type to pivot to determine if a field is required or not
... I think that gives a better anchor

<dmitriz> +1

ken: rather than a sorting it out from properties

burn: lots of +1's but no one joining the queue

yancy: I think what I'm saying is in agreement with what was just said
... the type in the proof section, would define whether credentialSchema was required as well

<ken> I agree with Yancy

ken: and specifically anoncred requires it

<dmitriz> https://github.com/w3c/vc-test-suite/issues/44

dmitriz: so, unless there's an objection, then I propose we close the issue

yancy: so, I thought credentialSchema was required
... and it must be one or more credential schemas
... 5.4

manu: yeah, let me clarify that language
... we don't say you must have a credential schema
... but you can use credentialSchema to express data schemas, but it must be of a certain format, etc
... we do this same pattern elsewhere, I think
... we also use an "if present, then..." style elsewhere

<dmitriz> maybe we can add the 'If present,' to section 5.4?

brent: if the intention of it is that further information is needed to process the ZKP
... maybe the text just needs to be clarified to express that

manu: you mean in the ZKP section?

brent: yes. it says it, but it doesn't really say why

yancy: yeah, I was going to say that while you may not be required to supply it
... if you're doing ZKP style tests, then...
... I was mainly suggesting that we modify the test suite
... so only if it's a ZKP, then it's anoncred-v1 type

brent: I don't think that matches the data model specification

dmitriz: I think this will get naturally solved
... if we get another ZKP implementation
... and if they pass the schema
... I don't think it's worth preemptively modifying

burn: we need to wrap up on this
... so a few more minutes on this topic
... or zero minutes :)

yancy: I'll just wait until we have more implementation details
... I agree with dmitriz

ken: I think it's kind of news to sovrin and evernym that there are others using ZKP proofs
... so it might take more thinking on our parts to suggest ways of dealing with new styles of ZKP proofs
... so I think we're a little early in figuring this out
... and perhaps offline would be the best place to discuss this further

manu: just to agree with dmitriz, the current implementations work with it this way
... so yancy if you've got an alternative ZKP mechanism, you may want to specify it through a spec first
... so we can review it
... and I imagine your set of tests would be a different set of optional tests than the sovrin one
... every mechanism that I know of needs that schema
... but if one exists, then it would need a totally different set of rules, etc, for that particular type of ZKP

yancy: yep. that's fine
... I'll look into coordinating a spec for that
... I have more specifics to talk about, but it seems strange to me that there's really only one implementation that requires this
... so I think it'd be great if there were more implementations beyond sovrin and evernym

burn: I want to be sure the resolution dmitriz wrote earlier, hasn't changed

dmitriz: from everything I've heard, nothing changes for the test suite

<manu> +1 to that

burn: alright, any last comments for today?

manu: just to request that people do a top-to-bottom review of the spec
... and send PRs in for changes
... that would be super helpful at this point

dmitriz: I'm going to close issue 44
... if there are other questions, we can reopen

manu: burn do we want to set a target?
... there's no target, but I think we really should set one
... especially if we expect objections going to PR
... it looks like it needs to be in the next 2-3 weeks

burn: I agree with you
... it may seem premature
... but I was wanting to say by the end of the 3rd week of June
... but that's like 10-15 days away
... but we really do need a target like that
... if we wanted a goal to go to PR by the end of june, then we really have to hit that
... why don't we say the 25th
... so, finishing CR, going to PR
... so, bring in those implementations, you have 2 weeks

ken: do we need to rerun our reports?

manu: yeah, you have to rerun
... or rather it would be a Good Thing if we all rerun them
... dmitriz would probably mention on a call, or running the tests once a week

ken: k, if there are now changes, do I still need to rerun it

manu: yep, has to be latest and greatest
... and resubmit

burn: there are no police here other than us
... so it's not like there needs to be an automated script here
... just keep an eye on things

oliver: I'm OK with this, as long as implementers can submit after this period

manu: well...yes, but when we go into PR, we need to draw a hard line about what features got implementations, and which didn't
... so if JWTs don't get enough implementations, those would have to come out
... we want to hold on, so that can make it in
... but if you're saying that it'll be another couple months, then we can't wait that long or the spec would be in danger

oliver: yeah. thanks. that's clear
... I think it's a requirement to stay in the spec

manu: have you talked to yancy and others about JWT implementations?

burn: sadly, we're out of time. please take this one offline, use email, etc.
... it is the WG that makes this decision.
... at that point, it's the end of the line and we'll ship it
... but it's the WG that makes that call
... Matt will be running the call next week
... I'll be on vacation
... do give Matt trouble next week
... bye all