<scribe> scribenick: dlongley
burn: Agenda for today is similar
to last week, unassigned issues, comment about TAG review,
progress towards CR, then working on PRs and issues. Time
permitting we'll ask for any updates on the test suite. Any
suggestions for changes?
... Anyone joining us for the first time today?
stonematt: I have a guest, the Architect at Brightlink.
Dan Rocco: I'm here to observe and see what the WG is about.
<manu> Welcome to the group, Dan!
burn: Charles Nevile from Consensys joined today but has a conflict so can't join. I'll let him formerly introduce himself if/when he can make it onto a call.
dezell: I work towards/with NAACS and Conexxus continue as co-chair at the Web Commerce Interest Group.
burn: We have a few new issues that aren't assigned to anyone. Issue #419.
DavidC: The holder ID used to be in the presentation like the subject ID was in the credential. It was removed for privacy issues supposedly per the TPAC meeting but I don't remember that. If you can figure out who the holder is from the proof in the presentation then it makes no sense why it can't be in the presentation.
burn: Can anyone like Brent or someone else from his team take it?
Brent: I can take it.
burn: Next: https://github.com/w3c/vc-data-model/issues/414
Brent: I need to get a PR in for that after meeting with Dave and Manu one more time.
burn: We can assign you though?
Brent: Yes
burn: I will take https://github.com/w3c/vc-data-model/issues/413
... https://github.com/w3c/vc-data-model/issues/408
... David?
DavidC: It seems that there's a hole in the spec now because we talk about holder more than subject but when we get to verification we talk about verifying the subject not the holder, seems like a gap that needs to be filled there.
burn: Anyone willing to take the issue?
manu: I can take the issue, I understand what he's saying and agree with it. I will try to put a PR in, I have to go through section 9 anyway.
burn: Thanks for taking that
one.
... https://github.com/w3c/vc-data-model/issues/406
DavidC: Discussion has started about this, Joe agrees there's a problem with the conformance statement that says this spec can't be used without an authorization framework, etc.
<stonematt> +1
burn: Matt, I'm going to assign you to this one because you already have a PR.
stonematt: Ok.
burn: https://github.com/w3c/vc-data-model/issues/405
DavidC: Again, discussion and PR started on this, it's progressing well. burn: Same thing -- Matt, this is yours.
stonematt: Ok.
burn: I was all prepared to write
up the PR to ask the TAG to review our spec, last Friday ...
when I realized that there is a requirement which I knew about
to point to their security and privacy questionnaire.
... But perhaps that's not the one we responded to. The one we
did before is not the current one.
... I've asked David to take a look and see what alignment
there is between the two and what it would take to apply our
responses to the current version.
... Anything you'd like to say, David?
DavidC: It would be nice for someone else to QA my work. I would prefer so someone else would review what I say.
Dmitri: I would like to help QA it.
DavidC: I'll email you first draft and then you can give comments.
Dmitri: Perfect, thank you.
burn: Thanks guys, lots of work to get to this point and I think that's the last piece that was missing, thanks again so much, Dmitri and David. I will ping you pretty frequently if I don't hear from you, please update me as often as you're able.
burn: I know Matt walked everyone
through this before and these are items that we saw were items
that we needed to go through before CR and there are items that
count up and some that count backwards from 99. There are a set
of things we need now and some right before CR (the 90s group).
We've completed items 1-6. But then we came to a screeching
halt.
... We voted to publish working draft but it's still not done,
a lot of is it administrative stuff. It's good we're hitting us
now because it will help us with CR. Frustrating that we're
three weeks behind though.
<Zakim> tzviya, you wanted to comment on TAG review
tzviya: I just wanted to comment on the TAG review -- I don't think that doing the security and privacy review is required before submitting to the TAG. I believe that the TAG finds it kind of annoying if you give them the document right before going to CR. They prefer more heads up. I feel that the sooner you give them this the better. Maybe a note that security response is pending.
burn: We can say that we completed an earlier version with PING and say we're updating to the current version and say we'd like to start review the now if possible, good?
tzviya: Yes.
burn: Ok, I agree with you, this
is one of the blockers that needs to happen.
... I was waiting to ping other groups until we sent something
to the TAG so this is good.
... I was going to find out from those groups if they have any
additional comments.
... This will help quite a bit, thanks Tzviya.
... After TAG review we need to close out our CR blockers. One
of the things, Manu, if you could take a look at the newly
assigned issues are CR blockers. Perhaps "gaping hole" is one
of them.
manu: Yes, I will review and mark things as a CR blocker.
burn: Yes.
manu: There will be a tension
that know how to spec lawyer can say things are editorial and
aren't really CR blockers.
... The second something is marked as a CR blocker the editors
have a very strong motivation to close it out as quickly as
possible and push something into the spec for that. I'm looking
for guidance from the group... without it I'm going to be very
lenient and not mark many things as CR blockers.
stonematt: Anything that we think might affect a normative section we mark CR blocker otherwise we can wait.
manu: Another option is punting to version 2 for certain things.
stonematt: Maybe we want a tag for CR-2?
manu: I didn't say CR-2, I meant version 2 as in not for the WG.
stonematt: Oh, I see.
... That's a bigger lever to pull.
manu: Yes, but one we need to
start pulling, happens once you start hitting CR.
... The group has to decide that things might be good points
put that they won't be dealt with in this version.
burn: Yes, you're correct, Manu.
We're at a point where we need to say no to new things. There's
sometimes a gray area between fixing things and doing new
stuff. We already said no new features last December. We're
done with that.
... Anything that is going to be necessary in order for
implementations to implement the specification will probably
end up being a blocker either now or after CR once discovered.
I agree all sorts of editorial things can be fixed later.
... The key is that they don't change the conformance reports
that are coming in.
... Effectively.
... As you know, when you change normative behavior then you
have to have a new CR. It's perfectly fine to argue strongly
for deferral at this point, a strong argument must be made for
a change to go in now as opposed to later.
... We can't put CR-2 because that's not how CR works as
currently defined at W3C.
... Anything else on that topic?
... I will send out the request for TAG review and the request
to the other groups. Other things we do identify at-risk
features, verifying requirements met, test suite finalized,
implementation report, etc.
... I'm very concerned we won't have a CR published before the
F2F. One of the challenges for this is --- is what should we
use our time at the F2F to do? We decided to tack this onto
Rebooting for convenience. I want people to think strongly
about what would be good agenda topics because beginning next
week that will be our focus.
... That's coming up at the beginning of March.
... The charter ends at the end of March.
... We will be asking to renew the group very shortly. I would
really like to have CR published before we officially make this
request and the chairs will coordinate with Kaz before making
the request.
tzviya: I will advise you as an AB member that you should publish CR before the request is made. It looks a lot better to the AC if it looks like something that's more on its way. I know as someone participating in this group that we're almost there but it looks to the rest of the AC that there's something that's so close to finished is fine.
burn: My understanding -- I spoke
with Wendy and talked about this and she said that an
administrative extension up to 6 months does not require an AC
vote. That CR in particular is good to have but it's understood
to have... in our particular case we have major input that came
in late but it's valuable input.
... We would have been at CR now if we chose not to accommodate
JWTs or ZKPs.
<kaz> s/awell/well/
burn: But we all agree the spec
is better because we incorporated that. So the extension should
not be a problem. Despite that the chairs are working hard to
get to CR.
... We have not been holding back or slacking off on
this.
... Thanks, Tzviya, we're working on this.
... Any other comments?
<brent> s/awll/well
<burn> https://github.com/w3c/vc-data-model/pulls
<manu> https://www.w3.org/2018/Process-20180201/#charter-extension
<manu> Looks like what Dan just said *is* a thing...
burn: All the links are in the
agenda too.
... Thanks for the link, Manu, for the up to 6 months maximum
administrative extension per the process document.
<manu> https://github.com/w3c/vc-data-model/pull/384
manu: Some of these PRs are
turning out to be controversial. They are not editorial
changes. The first one is a clarification...
... We have gotten a number of review comments in, none through
the issue tracker, but people saying they don't understand the
difference between ZKPs, JWTs, and Linked Data Proofs -- "what
should I use?". This PR was an attempt to do a factual
side-by-side comparison.
... You can/can't accomplish this with X, Y, Z.
<stonematt> maybe this is a WG Note?
manu: There is push back for
putting that into the spec. It was meant to be kind of a fairly
cold analysis of what you can/can't do today with the various
proof formats.
... We need folks to weigh in on that.
stonematt: We have a couple of working group notes -- is something like this better suited for a note?
manu: We could do it as a note, one place that we could do it is implementation guidance. The only thing is that people might still have the same confusion about using one or the other. What we could do is put something in to direct people to a link for people that want to know this stuff.
<TallTed> +1 appendix for this kind of "pick your tech, based on your requirements" table (because appendix is definitely linked from the main body; the NOTE would have to be published, or at least assigned a link, before CR, to do same with a NOTE)
manu: Editorially I would like
not to do that -- they are asking that question as they read
the spec and as long as the comparison is even handed it should
be fine but there's concern there will always be bikeshedding,
etc.
... Ted suggests putting it in an appendix -- which I think is
an ok compromise so it's still in the spec.
<gannan> +1 for appendix
manu: We need other people to weigh in, that PR's at a stand still until people weigh in.
<stonematt> not CR-Blocker :)
Kaliya: I think it should go in the spec and the appendix is a good spot for it.
manu: Anyone else have strong feelings?
<DavidC> +1
manu: Anyone feel that it
shouldn't go in the spec at all? Both Pelle and Oliver, I
believe said it shouldn't go in the spec at all.
... Any other strong opinions?
... David, what's your +1 to?
DavidC: I support putting it in the appendix.
manu: Ok, I'll rework the PR and put it in the appendix and people can object to that if that's a problem.
<manu> https://github.com/w3c/vc-data-model/pull/412
manu: This PR has to do with the
subject only property. When David Chadwick was writing the
subject-holder relationship section. One use case was that the
issue could say that the VC should only be used by the subject
and I did a PR so that could be just another terms of use use
case. I think your concern is that ... if you're going to do
that for subject only when not for issuance date and so
on.
... I think that's a legitimate push back on it -- there's a
question about where we're drawing the line in the spec. There
are things that could be modeled as terms of use and other
things where we call it out as a special property.
... So -- should we model subject-only as a special property or
put it in terms of use.
... We need to hear from implementers on this. If we postulate
a way for it to be done through terms of use it can stay in the
spec, otherwise it gets removed from the spec without
implementation support.
DavidC: When I wrote it initially
I put it as a Terms of Use thing. The problem was that the
conformance statement was not that the verifiable credential
was invalid if someone else presented it but it was the choice
of the verifier. The subject-only is independent of the
protocol and who the verifier is. Just like expiration date and
issuance date.
... So it was intended to be independent of any use.
... And that had to do with conformance.
manu: I don't know if I agree
with that but we shouldn't debate it here. That's good, it
gives me a different understanding of what you were saying,
let's discuss more in the issue.
... If people don't implement subject-only... I don't think DB
is planning on implementing it and we'll have to mark it as a
feature at-risk and then it will potentially be removed
entirely. I don't know which implementers will do it.
DavidC: When it was Terms of Use
it was marked at-risk. Terms of Use as such will be implemented
by two or more implementers but there may be no specific terms
of use that's implemented by two implementers where as the
generic Terms of Use will be implemented by two or more.
... It seems there's no real difference whether it's a single
property or a terms of use.
<stonematt> Implementation List: https://docs.google.com/spreadsheets/d/1SzfAUA0J72-1BORHJEmY4cdZrQ6vmKy4oq_24r_NwB4/edit#gid=0
manu: I think DB would at least
be more willing to support it as a Terms of Use but not as its
own property.
... I don't quite know what to do with this one, you make a
good point.
... David, you're saying you'd rather have a separate property,
I'm saying DB might implement if it was a Terms of Use.
... We need more implementers chiming in -- if only DB chimes
in we know it will have to be removed from the spec. Another
option is to say "one way to do it" in the spec.
... Then it's not normative and it won't get removed as a part
of CR.
<brent> +1 to SubjectOnly being part of terms of use
DavidC: If you don't tell people how you do do it -- people might implement things that are in the spec in different ways. You don't get interop. If we don't say anything people do their own thing and even when we do say sometimes they do that.
<DavidC> do that ->do not do that
stonematt: As an implementer, Brightlink is thinking about this right now. We'll add ourselves as an implementer in the next few days probably. I will be advocating implementing Terms of Use internally. I think it's a market need and implementations would prove that. If it's part of Terms of Use, it's an easy example where I can do subject-only as a Terms of Use implementation and it shows how to meet the two-implementation bar for Terms of Use.
<Zakim> burn, you wanted to say we need to take offline
burn: It's time for next steps.
<stonematt> +1 leaning toward putting it in ToU, so we have a crisp example of a useful ToU
manu: Brent wants it in Terms of Use and Matt said something to that effect -- and it sounds like if Brightlink and DB implement it we get Terms of Use implementations and one way of doing it.
DavidC: It would be an excellent way of killing two birds with one stone.
<Zakim> burn, you wanted to do chair interrupt
Orie_Steele: CTO at Transmute.
<brent> peta recommends "feed two birds with one scone"
manu: The other PRs are from matt and I think they are progressing nicely.
stonematt: I think I responded to most of your points, not completely aligned but good progression.
manu: Ok, that's it for the PRs.
burn: Any kind of update for us?
manu: We've had no progress on the test suite over the last week, we're blocked on that. Ganesh/Dmitri, we either need code to start going to the test suite or someone else has to pick that up.
gannan: Got it.
dmitriz: Ok.
burn: Anything else before we
close?
... Ok, thanks all, look forward to talking with you next
week.