<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?
manu: zero
... no new PRs, we're done
<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
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
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
<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
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]