Agenda

<stonematt> https://lists.w3.org/Archives/Public/public-vc-wg/2019Jul/0010.html

<rhiaro> scribenick: rhiaro

stonematt: A key goal for the meeting is to begin a transition for second CR. That has some schedule implications
... our charter ends in September, the CR period is 28 days, and then we can transition to PR
... The CR is going to be very narrowly focussed on the JWT work
... Then we'll have a strategy discussion about PR
... We've got a few items on the agenda - outstanding pull requests, issues
... Anyone have anything else for the agenda?

PRs

manu: zero
... no new PRs, we're done

Issues

<stonematt> https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is%3Aissue+is%3Aopen+-label%3Adefer+

manu: there are really three issues that we should look at
... issue 526 is an admin thing
... the iat to nbf changes, I merged that PR in and marked it as seven day close. I merged it because regardless of which way we went it needed to be merged anyway
... and we had a wg resolution to close that issue and pull in the PR
... that should be closed soon

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

manu: Ted and Joe raised issues in the last 24 hours which I haven't looked at
... 704, Ted saying it's editorial

TallTed: There are two options, one is to have two blocks of code one with clean json, and one is to have a line to explain why it's not valid json
... It shouldn't be a json code block if we're including stuff that makes it syntatically invalid json

manu: I'm agreeing we should put in language to say it's not valid json

TallTed: that's the minimum, I don't like it, if we do take that route we should put it for every json block that has a comment line
... I know it's a pain

stonematt: can we caption code blocks?

manu: we tried captioning before and it did not.. there's too much to say
... I think it's fine every single code block, it's just the first two examples

TallTed: I would have put in a PR, I only noticed it last night

manu: I'm checking the other examples now, only examples 1 and 2 have annotations, every place else has a green highlight
... I feel strongly against taking the comments out, so lets highlight those examples it's not valid json. Example 30 has a comment too

TallTed: I'm saying have another block that has them without. Keep the block with the comments, but also have a valid block without them for people who can copy and paste

manu: I'm -0.4 for that because it's duplicating stuff
... the assumption is if you're working with json you'll know those lines are invalid
... so we can say this is invalid json, strip out the //
... it's a compromise

TallTed: it's a question of whose life is easier. I'm not going to fight it

ken: example 6 where it says proof: { ... } there's a comment there as well

manu: that's all over the place
... all of the examples would be invalid in that case

TallTed: if they've all got ... they shouldn't open with the curly brace
... if they're showing excerpts, showing { ... it could just as well open ...

manu: there is structure around the ... to specify whether it's an array or an object
... the stuff around the ... is important for the example

TallTed: right

manu: we could make a statement early in the spec that says the examples are annotated in ways that make them invalid json,s pecifically we use // to annotate lines and we use ... to specify that there's other information in here where the contents are unimportant for the example
... we say that early on in the document, I don't know exactly where..
... Probably in the how to read this, the rfc must should text

TallTed: that's a reasonable place to put it
... we could put the wordy warning in one place and do a link to the wordy warning at the other places

manu: my only concern with that is we'd have to put it in every single example

TallTed: I agree

manu: grrr

TallTed: it's a pain, I'm sorry

manu: I don't think it actually helps, I think it's extra verbosity taht's not going to help people read it. An implementor will look at it and know that ... means something goes there

dlongley: I was going to suggest we make a note in that same section at the beginning that talks about the examples, that says if you would like runnable exmaples please go to the implementation guide, and we can put some that people can copy and paste and run over there

TallTed: it's viable to the extent that people read the implementation guide. People just read the spec. Yes JSON people should already understand this and recognise it when they see it. Not everyone is going to be a JSON person

manu: it has to do with the audience for the document
... shoudl we work this out in the issue tracker?
... it seems like we have some idea of some things we could do and instead of using call time we can use the issue tracker

<stonematt> ok dlongley

<Zakim> dlongley, you wanted to suggest that if you run runnable examples go to the implementation guide?

TallTed: fine with me. It's editorial, not normative

manu: correct
... it is editorial

<brent> +1 to editorial

stonematt: How is it affecting the CR process and vote today?

<brent> +1 to this not affecting CR or PR

manu: shouldn't affect it all. It's editorial, we can make editorial changes when we go to PR. We can note that there will be

stonematt: Then I'm +1 for tracking it in github

<ken> +1 to editorial

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

manu: Moving on. 705 is next
... Joe raised an issue 19 minutes ago
... Joe and Matt raised this..
... Stating that the verification dfn is problematic and we should use another definition

JoeAndrieu: it came up in the use cases, riiks wanted to see a distinction between verification and checking status
... as Matt and Tzviya and I were working through it, at first verify wasn't in the list (verification), and when mat tpointed out that definition, that's conformance with the spec but not what the rest of the document means with things like verificaiton method and what a verifier does etc

manu: I just want to make sure we're not talking about validation? We defined that as a working group and I'm concerned that checking credential status for ?? is a validation step not a verification step
... verification is conformance to the data model

JoeAndrieu: I don't think that's correct
... this is about what 'verifiable' means in a verifiable credential
... verification is the thing that makes these credentials different. We have to define that
... even if it's slightly off of the distinction you're making between verification and validation

manu: I would disagree with that, I'm concerned about kicking off another discussion around .. let's just go with the text that you're suggesting and see if there's any disagreement

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

JoeAndrieu: I put in a PR 5 minutes ago.. I tried to put some text in, I'm not fully happy with it
... because what I quote from elsewhere in the document, we say this elsewhere let's just use that, but when I put it as a full dfn it was wanting

TallTed: we do have a bit of a rathole here and I don't think it's avoidable
... there needs to be a distinction between a structural validation (following the model) and a validity of this credential which is checking the signature and date and those things

stonematt: the line we don't want to walk down is what's acceptable. That's the whole judgement subjectivity thing

brent: we have in the terminologoy section verification and it's defined strictly as comparing with the data model. The validation definition seems to be what joe is wanting to make the new verification section

JoeAndrieu: that's interesting

brent: we have validation saying this is what the verifier cares about
... there's also another line somewhere saying this is necessary in order for a credential to be a verifiable credential

stonematt: it has to do with the signature stuff

manu: my biggest concern is we're opening up a big can of worms by having this discussion this late. I'm going to try to make an arguement that the thing we put in the spec - we had multiple wg meetings for this language, a ton of discussion - verification we were very careful int hat definition... whether a VC complies with the spec, includes checking credential status. Any time there's a must or may in the spec that's a part of verification

<TallTed> maybe change "verification" to "verifiability" because it's not really verification that's described

manu: Here's why putting that extra sentence in there opens a can of worms. there are some things w ecould argue into the ground as being verification or validation and there arguements for either side
... there's a grey area
... specifically the revocation of a credential is one of those things in the grey area
... some verifiers will look at it and go you know what, whether or not the crednetial was revoked is unimportant to me
... i can look at something as valid even though the credential has been revoked
... whereas others will say if it has been revoked it fails validation
... the problem with adding things to the dfn is it will force some of the things in the grey area into the verification bucket or the validation bucket which will kick off a whole bunch of disagreements
... the reason we picked the dfn that we did is because verification is if there's a must or should or may then it falls into the verification bucket
... validation has to do with your business logic

<TallTed> "conformance with this spec" is not what's happening when you're evaluating revocation, nbf, expiration, etc.

manu: if your business logic is different from someone else's business logic then it's a validation thing that's going on
... Ithinkw e can wordsmith it, we can use the issue tracker, but it's the wrong time to be doing this
... everyone's dfn of right is going to be slightly different
... happy to have the group try to revise as much as they can

<Zakim> JoeAndrieu, you wanted to say its not that gray

JoeAndrieu: +1 to taking it to the issue

<TallTed> Right now we've got what looks to me like overlapping spiral definitions, not quite circular, but close.

JoeAndrieu: I also am frustrated by the last minute bikeshedding which this feels like. But I don't think it's as black and white
... It hink VCs do something specific so you can verify them
... that's different that the business rules of the verifier

<TallTed> I don't verify that I can verify.

stonematt: the thing I'd recognise as a verifier is you can verify a credential that was valid at one time but isn't any more but you can still verify
... we're getting into the policy thing about revocation. I always get tripped up by revocation because the status has been withdrawn by the issuer vs the keys have changed and it's not trustable any more

<Zakim> stonematt, you wanted to say so you can verify an invalid credential (one that's been revoked)

stonematt: that's not the revocation discussion, that doesn't verify that the security/signature stuff is at riks, but the status is the thing we're focussed on here

ken: in section 5.1 we talk about verification but we don't mention validation as a separate step they might take that is beyond the scope fo the spec
... we say where you shold verify which includes checking credential status, but once ?? not making that clear distinction in taht useage, our terminology is kind of loose in terms of verify vs validate

<Zakim> manu, you wanted to comment on validation and move to issue tracker/PR...

manu: next steps.. I'm heairng lets taking it back to the issue tracker and try to come to some sort of resolution there
... ken I note we have an entire appendix on validation. We're not clear you're right, we're not clear on purpose, we couldn't come to agreement, there were too many times where it was not clear whether something is verification or validation and it really came down to someone's viewpoint

<TallTed> This spins far out of "data model" and into use...

<brent> +1

manu: joe I hope you are right and it's not as grey as we think but we got to the dfns we have in the document because there was so much grey area and that's what we could get people to agree to

<burn> +1 TallTed

<Zakim> burn, you wanted to ask who call in user 4 (area code 615) is

<brent> scribenick: brent

dudley: I am CIO at university admissions center in australia
... we provide services across australia

<gannan> I believe the website is https://www.uac.edu.au/

dudley: real privilege to be hear, new field of technology

stonematt: lots of +1s from this group
... PR and issue discussion is done for today

Is the document ready for PR?

stonematt: anything keeping us from PR, what is lurking in the shadows?

burn: before we got here, I thought we were going to close off Issue 526.
... A vote to publish will have to have a "assuming this is pulled in" which is weaker.

manu: we can try iat-nbf because oliver is here
... the administrative one is not resolved yet.

burn: I thought we discussed this yesterday. I think the problem is with the spec

manu: 526 is handled, in the PR and CR docs, I thought we were keeping it open until the TR is fixed as well

burn: Either the link in the spec needs to be fixed, or the re-direct needs to happen.

manu: both PR and CR have been updated to point to the appropriate palces.
... link to the documents in the current version assume sysrec is going to update the links when we publish.
... this should have been done months ago
... the title is wrong in TR space.
... maybe Dan can clarify this in the request. If we don't fix it now, it will be broken for a long time.

burn: but the pointer to the date3d CR doc is fixed

manu: but sysrec hasn't finished
... that link doesn't re-direct

<Zakim> manu, you wanted to provide status update.

burn: 7 days ago it did something, so now I'm confused.
... I will look into 526 again

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

manu: that will stay open. Is oliver here?

oliver: yes

manu: are you and ted happy with the resolution to this issue?

TallTed: I'm good with the PR

oliver: I'm also good with the PR

manu: we have confirmation and can close. Anyone else disagree?

stonematt: we are deciding based on that confirmation to close this issue?

<ken> +1 close

TallTed: the thread of conversation we were just having says to me that everyone needs to read the spec again and make sure there is no protocol, no action
... this is what the field is for, not this is how you do it. Even the lifespan is problematic it is outside of bounds. This stuff happens during protocol activities

<burn> I have closed issue #667

TallTed: feels problematic to put this out there that makes it seems like we have defined protocol when we have not

stonematt: Joe and I stirred the pot. we have a lot of things in the use case document that is very much running ahead of the data model.
... we may have driven too much of that into the data model. which led to the question about verification
... Maybe this is more of a definition for the use cases

TallTed: I think the terminology doc needs to be split

manu: propose a way forward. we are trying very are to get a second CR. we have to decide on that today.
... same with the PR doc, we have to signal we are on a path to finish.

<burn> +1 manu

TallTed: we can't continue say process flow is the ruler because process flow is going to make this doc useless.

manu: it is never done, only in various stages. we continue to work on it. question is, is it good enough for people to use.
... I think all of us agree these are editorial.

<Zakim> manu, you wanted to propose a way forward.

manu: we are working within the constraints of the W3C. I don't think the document is in a state where we should kill it.
... what I'd like to get to today is a signal to the director that they can move forward.
... we have roughly a month to figure it out. It would be a real shame to even suggest killing it.
... I'm hoping we can get to voting on CR and PR today. and mention we may make editorial changes.

DavidC: question for clarification: Can we make editorial changes in the PR?

manu: two classes of changes. First, we can make editorial changes during CR.
... we are going into a second CR. We can make editorial changes after that before PR.
... there are two changes that can be made during PR: one is editorial stuff, the other is additions from the director.
... we are at the end for version 1.0
... we need to not derail the problems.

DavidC: why can't we go right to PR?

<Zakim> burn, you wanted to say that PR is final

stonematt: the plan is to address these before PR

burn: after PR, no changes.
... we have made a large number of non-substantive changes.
... we could go to PR if we didn't have iat->nbf change

now we are going into another CR, so we can make some non-substantive changes. people love to make last minute comments

scribe: we need to hold the line. No changes after PR. Non-substantive before PR, yes.

stonematt: queue is clear
... based on that discussion, it seems we are moving to the discussion about the vote.

<manu> +1 to talk about 2nd CR

<oliver> +1

<ken> +1

<DavidC> +1

<deiu> +1

stonematt: anything else to bring up?
... manu, do you have a proposal?

manu: I can provide the link, explain why we are doing this. If we remember the discussion from last week.
... there was a bug in the spec, so after making the change we need another CR.
... the good news is it only needs 28 days and we can seek comments only on this one small thing.
... because we already took comments on everything else.
... we need wide review on this one feature.

<manu> https://w3c.github.io/vc-data-model/CR/2019-07-25/

manu: yes we are doing another CR, it is focused on this one thing, but we may make editorial changes
... this is prepped to go out thursday
... so we need to vote today
... it is clear we are only taking feedback on the iat->nbf change
... does the group want to publish the linked docuement on this thirsday for a 28 day CR period
... chairs, is that in alignment with your plans?

stonematt: yes.

DavidC: oliver, verifiable presentation iss is the issuer, the verifiable presentation doesn't have an issuer.

<burn> agree with Manu

manu: this is the worst time to bring things up.

<burn> Better now than later, but better not than now

manu: at this point it feels like the JWT stuff is not ready to ship, if we're finding more bugs.

oliver: basically, we have two options. Either we have a q-

manu: this is really bad

burn: yeah, manu is right. this is exceedingly bad. another group WebRTC had its first CR two-three years ago. they are still not done.
... the problem is, each tweak introduces other changes
... if there is something that absolutely must be fixed now and no chance anyone in the universe may object.
... but it is better to do nothing thatn something if there is any chance it could do this.

<DavidC> Suggested solution is for VPs in JWT format, the iss field is mapped into holder in the VP

oliver: I don't insist on this. don't insist on additional mapping. the spec allows adding the holder field

<burn> It might be better to rip the JWT stuff out. If it really isn't ready it should be pulled out

oliver: the spec as it is allows us to do what we need to .

<Zakim> manu, you wanted to mark section at risk *again*, marked for removal if there is another bug that's found...

DavidC: I'm not clear on the proposal

oliver: my proposal was to use the holder attribute if we need to inside of the vp property if we need to

stonematt: so we propose leaving the spec as is

<burn> Agree with Manu that if we make this change we need to also mark JWT section as at risk again in case of another bug

manu: checking to see if this is an editorial change
... iss must represent the issuer property

<Zakim> manu, you wanted to mark section at risk *again*, marked for removal if there is another bug that's found...

manu: what is the proposed change?

DavidC: add that it is mapped to the holder.

<oliver> +1 brent

<dlongley> The spec says this today btw: "If a JWS is present, the digital signature either refers to the issuer of the verifiable credential, or in the case of a verifiable presentation, the holder of the verifiable credential."

oliver: why is the spec wrong? we can use the holder field.

DavidC: look at example 30. a JWT payload of a verifiable presentation.

oliver: as far as I understand, we are talking about the iss field of a verifiable presentation. this is outside of the spec.
... i get your point. the way it should work is to add the holder attribute to the vp section of the JWT
... we could change the example.

manu: here is what I'm proposing. We mark the whole JWT section as at risk.
... otherwise the whole spec is at risk.

<Zakim> manu, you wanted to mark section at risk *again*, marked for removal if there is another bug that's found...

<dlongley> +1 to marking JWT section at-risk; this is the last chance -- any failure and it gets removed and has to go into a different document, can't risk the rest of the document on it.

manu: the JWT section to be moved into its own spec if additional changes need to be made after we go into CR.
... we will go into a second CR, mark the JWT section as at risk.
... we have to go into a proposal.

<Zakim> burn, you wanted to explain about feature maturity (if Manu doesn't)

burn: this happens. if there is a feature that isn't mature or implemented enough, groups do this and move things to their own spec because its not worth jeopardizing the rest of the spec.

<TallTed> +1 JWT At Risk (and I think it will probably have to be pulled to a Note for this WG)

burn: if we end up making a change along the lines of what david wants, which is a substantive change that others may nto agree on, we would have to remove it.

DavidC: We go to the second CR with the whole section marked at risk. If anything else comes up that requires a normative change, we need to pull it out into its own spec.

manu: If you can get some text that you and Oliver agree to on the call today, we might be able to move forwar, and the rest of the JWT developers need to agree.
... we mark the whole section at risk, and if anyone disagrees, we have to pull it out.
... please have text to propose by the end of the call.

oliver: The text can also contain normative changes, i.e., making the iss field mean the holder in a presentation.

manu: yes
... I suggest, do the normative thing if you need to address that

burn: more prcisely: when you do another CR, you can make normative changes.
... if you want to go from CR to PR, you can't make a normative change unless you warn that a normative change may happen.
... marking a feature at risk allows us to remove it without requiring another CR.

jonathan_holt: can I clarify the issue? I thought the holder was the jti. Does that not carry over to the presentation?

<DavidC> oliver, here is my proposed changes

<DavidC> change iss MUST represent the issuer property. to iss MUST represent the issuer property of a verifiable credential or the holder property of a verifiable presentation change iss is present, the value MUST be used to set the issuer property of the new JSON object. to iss is present, the value MUST be used to set the issuer property of the new JSON verifiable credential object or the holder property of the new JSON verifiable presentation object.

<oliver> +1 DavidC

stonematt: Kaz is on the queue?

kaz: my comment is a general one, so can wait

DavidC: can jonathan repeat his question?

jonathan_holt: jti is used for holder, if present, doesn't that carry over to a verifiable presentation?

oliver: the jti is the id of the credential itself. the id of the credential subject is something else.

<TallTed> (non-normative but important) example(s) (#30, others?) will also need to change to match revised normative text.

<stonematt> from DavidC

<stonematt> change iss MUST represent the issuer property. to iss MUST represent the issuer property of a verifiable credential or the holder property of a verifiable presentation change iss is present, the value MUST be used to set the issuer property of the new JSON object. to iss is present, the value MUST be used to set the issuer property of the new JSON verifiable credential object or the holder property of the new JSON verifiable presentation object.

stonematt: can we get clarity on this? or at least a straw poll vote?

<oliver> +1 matt

kaz: maybe I can jump in now.
... as already mentioned, there is specific process descri for CR and PR publication by the W3C Process Document.
... we need to identify which issue is really fatal (=which makes the current version spec unusable and need to be fixed)) for the VC data model version one, and which issues could be deferred to the next version

stonematt: that's a good question to pose to our JWT colleagues.
... are you asserting that this is fatal to the spec if this doesn't go in?

DavidC: what does "fatal" mean?

stonematt: it makes the spec unusable.

DavidC: no, this is a bug, it doesn't make the spec unusable

oliver: i see it in the same way.

DavidC: it is a simple editorial oversight. when you add the extra dimension of verifiable presentation, you need more in the text.

burn: I think we are looping. as Manu said, oliver and david need to write the text in the channel before the end of the call.

<oliver> +1

burn: there will be text that goes into the document nefore the end of the call

stonematt: they have the text.

manu: I don't think it is there.

<burn> as i said, Manu, a PR, right now

manu: we need something that can be copied and pasted into the spec
... we need the text that is going to go in the spec.

TallTed: The best way is to raise a PR
... then we can just approve it.

stonematt: oliver, is that something you can do?

DavidC: I think I can

stonematt: we have a few minutes while that goes through

<Zakim> burn, you wanted to suggest that oliver and david hang up and work directly with each other

burn: they need to do what they need to do, even if it means getting off this call and getting it done

<Zakim> manu, you wanted to make the CR proposal.

manu: here is the proposal
... presumes we will get concrete text
... any objections to this proposal?

stonematt: those are ANDs?

manu: correct

stonematt: I think that is the path we have been walking down

<manu> PROPOSAL: The VCWG approves the publication of a Second Candidate Recommendation based on the document available here https://w3c.github.io/vc-data-model/CR/2019-07-25/ for publication on July 25th 2019, for a review period of 28 days from the date of publication with two additions 1) the JWT section continues to be marked as at risk for removal (publication in a separate document), and 2) text is inserted to clarify how the JWT iss/holder are related in

<manu> presentations.

<manu> +1

<burn> +1

<deiu> +1

<stonematt> +1 to proposal

<dlongley> +1

<ken> +1

<TallTed> +1

<rhiaro> +1

<yancy> +1

<dmitriz> +1

oliver: the feature at risk will be removed at the end of this month?

<DavidC> +1

manu: correct

<brent> +1

<oliver> +1

<drummond> +1

burn: as before, we need at least two implementations of the new feature and no substantive changes

RESOLUTION: The VCWG approves the publication of a Second Candidate Recommendation based on the document available here https://w3c.github.io/vc-data-model/CR/2019-07-25/ for publication on July 25th 2019, for a review period of 28 days from the date of publication with two additions 1) the JWT section continues to be marked as at risk for removal (publication in a separate document), and 2) text is inserted to clarify how the JWT iss/holder are related in

<manu> presentations.

stonematt: seeing no negative votes

<agropper> +1

<oliver> from before

<oliver> no queue

<Zakim> manu, you wanted to get something on the record for PR.

manu: so, are we ready to discuss PR?

stonematt: lets get on record about PR

PR Process

manu: the PR process, the assumption is we go through CR, it will end august 21
... we will immediately roll into a PR
... because the timeline is so tight: we publish CR, make an unknown set of editorial changes
... when august 22 rolls around we will publish a PR. Done done with this, unless there are extreme things the director needs to deal with

<manu> https://w3c.github.io/vc-data-model/PR/2019-08-22/

manu: the only updates we will make to the document are what we have already stated.
... removeing the feature at risk flag, or removing the JWT section if there is another bug.
... the proposal we are looking for today, the group feels (modulo the changes already discussed) as long as the only changes are editorial, then the PR will be published on August 21

<drummond> In favor

<brent> yes

<TallTed> +1 include JWT risk mention

<burn> yes

<ken> +1 to include JWT risk

<drummond> +1

<ken> +1

<Sercan_K> +1

<brent> +1

manu: any objections?

oliver: this external JWT document, what would this be like. Would it be normative?

<DavidC> +1

<oliver> +1

manu: the only thing the group could do is publish it as a note, non-normative

<manu> PROPOSAL: The VCWG approves the publication of a Proposed Recommendation based on the document available here https://w3c.github.io/vc-data-model/PR/2019-08-22/ for publication on August 22nd 2019. Editorial changes to the document referenced may be made based on consensus decisions by the group. The only section that is marked at risk currently is the JWT section, and if removed, changes will be made to the specification to reference an external JWT VC document.

manu: we will send a transition request before CR is ended.

kaz: we may need to wait until CR is over

<manu> PROPOSAL: The VCWG approves the publication of a Proposed Recommendation based on the document available here https://w3c.github.io/vc-data-model/PR/2019-08-22/ for publication on August 22nd 2019 (or the earliest possible date that the specification can enter Proposed Recommendation). Editorial changes to the document referenced may be made based on consensus decisions by the group. The only section that is marked at risk currently is the JWT section, and if

<manu> removed, changes will be made to the specification to reference an external JWT VC document.

<TallTed> +1

<manu> +1

<dlongley> +1

<DavidC> PR#707 has just been published

<burn> +1

<JoeAndrieu> +1

<deiu> +1

<yancy> +1

<drummond> +1

<rhiaro> +1

<stonematt> +1

<agropper> +1

<yancy> +1

<brent> +1

<ken> +1

<oliver> +1

<DavidC> <oliver> please take a look

<DavidC> +1

<dmitriz> +1

RESOLUTION: The VCWG approves the publication of a Proposed Recommendation based on the document available here https://w3c.github.io/vc-data-model/PR/2019-08-22/ for publication on August 22nd 2019 (or the earliest possible date that the specification can enter Proposed Recommendation). Editorial changes to the document referenced may be made based on consensus decisions by the group. The only section that is marked at risk currently is the JWT section, and if

<manu> removed, changes will be made to the specification to reference an external JWT VC document.

stonematt: thank you everyone for those two items
... moving us toward getting the spec out

pull request 707

<dlongley> https://github.com/w3c/vc-data-model/pull/707

stonematt: next let's look at the pull request

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

DavidC: I'm not sure what the funny characters are, I removed something.

TallTed: That's just saying those lines aren't shown
... this does not touch the non-normative examples

They need to be changed.

oliver: the vp example already has this in the example

DavidC: correct

TallTed: nothing in the other direction that needs to be changed?

DavidC: the actual verifiable presentation isn;t shown, only the JWT representation

stonematt: any other comments on this pr?
... oliver and david, if you step back out the weeds, how would other JWT developers respond to this?

<gannan> your line is quite quiet david

DavidC: is this in the text suite? does it test vp as well as vc for JWT?

manu: It was tested for a credential, not for a presentation

DavidC: that explains why the bug wasn't found

manu: We should add a new test
... but the test suite is not normative

<TallTed> I don't know enough JWT to judge whether the PR is sufficient. Which is part of my reason to keep "At Risk". Definitely support adding new test (less time critical, but still needs be fast).

manu: it should be done today
... and you need to contact all the other JWT developers and have them re-run the suite after the new test is in.
... do we need a proposal?

<oliver> +1

stonematt: we need to get a decision on this pr. I assume david agrees, oliver?

<oliver> yes

stonematt: any other objections?

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

stonematt: no objections, let's pull this in. Do we need a resolution?

manu: yes

<manu> PROPOSAL: The issue concerning the JWT iss/holder relationship is resolved by PR #707, which makes a substantive change to the specification. The text should be included in the 2nd Candidate Recommendation publication along with a section marking the JWT feature as at-risk.

<manu> +1

<brent> +1

<dlongley> +1

<drummond> +1

<deiu> +1

<stonematt> +1

<ken> +1

<agropper> +1

<burn> +1

<JoeAndrieu> +1

<yancy> +1

<oliver> +1

<gannan> +1

<Sercan_K> +1

<TallTed> +1

stonematt: hoping to see olver and davidc vote

<DavidC> +1

RESOLUTION: The issue concerning the JWT iss/holder relationship is resolved by PR #707, which makes a substantive change to the specification. The text should be included in the 2nd Candidate Recommendation publication along with a section marking the JWT feature as at-risk.

stonematt: thank you everyone
... we are 7 minutes out. limited time for anything new
... salient item out of these changes are: need new test that represents this vp vs vc nuance
... who would create that?

dmitriz: I look to oliver

oliver: I will provide the test cases
... this week

<DavidC> <oliver> thanks

stonematt: thank you
... last order of business: heads up, one of our deliverables is the use case document. we are feature complete, we believe, but need an editorial review
... we will ask the groups consensus at some point to publish
... not looking for new use cases, but raise issues for editorial changes

AOB

stonematt: anything else today?

DavidC: heads up, very soon I am going to be working with the mobile driving license group
... not a very large change to them. helping to swing this so that mobile driving licenses conform to our data model would be big
... If they want to be involved, send me an email.
... I can request they be added as invited experts

stonematt: anything else?
... this was a tricky and challenging call. Good to get to CR, even with the caveats.

<drummond> Congrats to the whole WG

stonematt: now we need to stay on schedule. thanks for staying heads down on required changes
... talk to you next week

<stonematt> bye all

<kaz> [adjourned]