- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 29 Jul 2019 22:44:46 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2019/07/23-vcwg-minutes.html
also as text below.
Thanks a lot for taking these minutes, Amy and Brent!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Verifiable Claims Working Group
23 Jul 2019
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Jul/0010.html
Attendees
Present
Adrian_Gropper, Amy_Guy, Andrei_Sambra, Brent_Zundel,
Dan_Burnett, David_Chadwick, Dmitri_Zagidulin,
Ganesh_Annan, Joe_Andrieu, Kaz_Ashimura, Ken_Ebert,
Matt_Stone, Sercan_Kum, Ted_Thibodeau, Yancy_Ribbens,
Jonathan_Holt, Oliver_Terbu, David_Ezell,
Dudley_Collinson, Dave_Longley, Manu_Sporny,
Kaliya_Young, Drummond_Reed, Benjamin_Young
Regrets
Chair
Matt_Stone, Dan_Burnett
Scribe
Amy, Brent
Contents
* [3]Topics
1. [4]Agenda
2. [5]PRs
3. [6]Issues
4. [7]Is the document ready for PR?
5. [8]PR Process
6. [9]pull request 707
7. [10]AOB
* [11]Summary of Action Items
* [12]Summary of Resolutions
__________________________________________________________
Agenda
<stonematt>
[13]https://lists.w3.org/Archives/Public/public-vc-wg/2019Jul/0
010.html
[13] 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>
[14]https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is%3Ai
ssue+is%3Aopen+-label%3Adefer+
[14] https://github.com/w3c/vc-data-model/issues?utf8=
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> [15]https://github.com/w3c/vc-data-model/issues/704
[15] 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> [16]https://github.com/w3c/vc-data-model/issues/705
[16] 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> [17]https://github.com/w3c/vc-data-model/pull/706
[17] 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 [18]https://www.uac.edu.au/
[18] 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> [19]https://github.com/w3c/vc-data-model/issues/667
[19] 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> [20]https://w3c.github.io/vc-data-model/CR/2019-07-25/
[20] 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
[21]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
[21] https://w3c.github.io/vc-data-model/CR/2019-07-25/
<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
[22]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
[22] https://w3c.github.io/vc-data-model/CR/2019-07-25/
<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> [23]https://w3c.github.io/vc-data-model/PR/2019-08-22/
[23] 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
[24]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.
[24] https://w3c.github.io/vc-data-model/PR/2019-08-22/
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
[25]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
[25] https://w3c.github.io/vc-data-model/PR/2019-08-22/
<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
[26]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
[26] https://w3c.github.io/vc-data-model/PR/2019-08-22/
<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> [27]https://github.com/w3c/vc-data-model/pull/707
[27] https://github.com/w3c/vc-data-model/pull/707
stonematt: next let's look at the pull request
<manu> [28]https://github.com/w3c/vc-data-model/pull/707/files
[28] 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> [29]https://github.com/w3c/vc-data-model/pull/707
[29] 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]
Summary of Action Items
Summary of Resolutions
1. [30]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
2. [31]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
3. [32]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.
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [33]scribe.perl version 1.154 ([34]CVS log)
$Date: 2019/07/29 13:41:30 $
[33] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[34] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 29 July 2019 13:45:53 UTC