<inserted> scribenick: stonematt
<scribe> agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018Aug/0000.html
burn: agenda and meeting
review
... any suggesting/changes
<burn> https://goo.gl/V4XTBT
Mike Lodder, crypto engineer from Sovrin/Evernym
Chris Benton, have been in listening mode looking forward to engaging more
Lovesh Harchandani contributed PR208 will be here to discuss.
<burn> https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+no%3Aassignee
manu: I'll take the new editorial items
<inserted> scribenick: dlongley
stonematt: I had two or three
items of feedback come in this week.
... Couple of things - we have a response from the privacy
group PING, they are going to be discussing VCs in their call
on Thursday Aug 9th.
... At 12 ET.
... Member only, if you'd like to participate in that call ...
let me know. We don't want the private password going out. We
want our active participants to come, that would be great.
<manu> I will be there.
stonematt: I'm planning to join, it would be good for people to raise hands here to say if you are going.
<TallTed> I will put it on my calendar; can't guarantee presence today.
dlongley: I plan to be there.
stonematt: Second, item on
external review, is internationalization. I got a note from the
chair there, they put our request in their review radar and
over next couple of months (60 day response time) they will
review.
... If anything comes up we'll add it as an issue or get it
into the group.
<stonematt> https://github.com/w3c/i18n-activity/projects/1
stonematt: That's what we have so far, presumably the others are going along we didn't get more feedback yet. We got a note from ODRL about a quick question that Manu answered. If you are following the mailing list you'll see that discussion happen.
<DavidC> I will try to join the meeting on Thursday, I think it will be 5PM BST.
stonematt: Quick point of order,
is it ok to send the call-in details to the member mailing list
for this WG?
... What's protocol here?
kaz: Member list is ok.
stonematt: Ok, I'll send that out before end of day today so people have the details for the Thursday PING meeting.
<scribe> scribenick: stonematt
<burn> https://github.com/w3c/vc-data-model/pull/198#issuecomment-410783573
burn: Delegation was a large
discussion last week
... hope to finally pull in pr 198 based on that discussion
manu: I'm fine w/ pulling in PR
but there are a few areas that will need to be reworked. the
largest is the ideas of "delegation of attributes"
... let's pull it in and I'll make a pass on the reworked areas
that are datamodel affecting
<Zakim> manu, you wanted to note that there is still a bit of this in the s!=h PR, but happy to pull it in and rework it.
burn: are the any objections to pull this in as a starting point and rework some details
<Zakim> manu, you wanted to be specific on data model issues.
mike-lodder: will the other items be tracked by github issues?
manu: yes
... had the idea that holder could delegate credentilas to
others to use. last week, we decided not to do that and wait
for something like OCAP
... some details are still in the PR that implies that
possibility. we should remove that.
... don't want to enable the holder to allow another entity to
"use attribute x, y, and z" at this point
<manu> good idea, bigbluehat -- I can add that to the spec.
bigbluehat: other groups pull in
PRs with comments to indicate that there is still discussion or
a section is under dispute.
... respec may have language like "at risk"
TallTed: pulling in a PR that has
comments against it may lose some of the details. we have to
raise issues immediately as part of the merge.
... will have to complete a manual process to do this.
<burn> I have problems with the term 'at risk' - that has meaning for features being part of the spec or not, as opposed to something just still being under discussion
DavidC: will flag these sections
to indicate which still need to be resolved.
... manu is concerned with exact context and granularity of the
text.
... we can work through these items.
manu: you expressed the text differently in two ways.
DavidC: seems like DM supports that. I did that on purpose
manu: be consistent
DavidC: ok
burn: where are we?
manu: happy to make those modifications, unless you want to. or pull it in and I'll do it immediately
burn: other comments?
<manu> ACTION: Manu to raise an issue on delegation of attributes, reference the issue in DavidC's PR, fix minor editorial issues.
burn: YEA!!!
<burn> https://github.com/w3c/vc-data-model/pulls
burn: PR208, lovesh you wanted to be here for this discussion
<kaz> PR 208
lovesh: discusses ZKP ideas
<dlongley> summary document: https://docs.google.com/document/d/10e6lcsX0kiXkWX4_79hD1fb4p_AbFGsRm90eJJKFayI/edit
lovesh: google doc discussion
several ideas that the PR covers, so we can discuss out of
band
... it's a very large PR.
burn: there are a lot of great ideas in the PR. we have to get the IPR status resolved
Question: there are other authors that may not have IPR. can we close the PR and reopoen it w/ a single author?
burn: the IPR issue must be
reolved before we can even discuss this
... when actual text changes are proposed, it's better to make
multiple PRs
... even though it's a lot of work to do that, it's also
difficult to read and respond
... it's ok to get general feedback, and later open a new PR
that focused
lovesh: would like feedback on ideas
burn: individuals can give their opinion of the content, but we won't make a formal acceptance until IPR is resolved.
kaz: need authors to be registered with the WG before submitting content. Please have Evernym nominate Lovesh
<Zakim> manu, you wanted to note general feedback...
manu: I provided some general feedback in the document based on the direction the group has been going. there is a concept by concept response in the document. 1.a, 1.b, etc would each be PRs
<mike-lodder> Ideally yes but realistically no
<dlongley> mike-lodder: you may be able to combine some of those if they are conceptually close enough
manu: I think there would be 24 modifications. about 9 are substantitive changes, about 4 are possible and 5 that will need discussion
<mike-lodder> Dlongely: agreed
lovesh: I will work to formally join the group
kaz: I'll help
mike-lodder: let's squash related content into a single PR, we don't have to do 20 prs
<Zakim> manu, you wanted to note it's okay, but the larger a PR becomes, the more difficult to pull it in.
<dlongley> it's a balance of time/effort with authors and reviewers (all volunteers here)
stonematt: +1 to combining PRs where reasonable
manu: the more text that changes in a PR, the more opportunity you give people to argue. Keep the changes focused.
burn: perhaps you could try to restructure it into PRs that are related/focused on more singular concepts
<burn> https://github.com/w3c/vc-data-model/pull/210
manu: refresh service allows the
issuer to time limit a VC that's different than the underlying
license and force it to be updated/refreshed.
... DavidC some data is private, maybe we put it in the
presentation, so holder can choose how/when to share it
<mike-lodder> This seems like an implementation optimization
<mike-lodder> DavidC +1
DavidC: how the hodler get the VC is a protocol issue and we're not discussion protocol. refresh service should be reserved for when we discuss protocol.
<Zakim> manu, you wanted to note either or makes implementations more difficult, can we start in one place and expand further later on?
manu: in general, i agree,
but...
... there is a nuance here. there are certain properties that
will be used in the protocol, for example signatures. I'm more
concerned about the use case.
... if we're going to say "we not going to support a refresh
mechanism in version 1.0" i'm ok w/ that.
... V Profile is the thing that the encapsulating data object
that will flow across the protocol, so it might be the best
place to put it.
... are we going to support a refresh process?
DavidC: when it's verified wouldn't the issuer respond with a refresh url?
<dlongley> scribenick: dlongley
<stonematt> manu: CCG is standardizing the protocol that deals with this
stonematt: I want to go back to
something you said before.
... One of the ways we see this verification process working
would not require the verifier to go back to the issuer, so
there wouldn't be an opportunity
DavidC: The holder, not the
verifier, sorry. The refresh URL is sent to the holder.
... This is similar to how oauth works.
stonematt: Ok.
manu: I think there's general/full agreement on how it happens. Holder does refreshing, gets message from issuer over the protocol. It just so happens that the presentation is used as the top level object. Do we spin up a whole new WG for that to happen or just do it here?
<mike-lodder> I agree
DavidC: The point I was making was that there will need to be a new WG to specify the whole protocol for the whole thing happening including revocation. Instead of picking out one item ... I think that's premature, do the whole protocol suite as a new WG.
TallTed: As been highlighted a number of times in recent weeks. This group is relatively near to conclusion. The kettle of worms we're looking at to address here is much more complex than it appears here. It's going to take a long time to resolve these issues, more complex than they appear.
burn: This needs more
discussion.
... And we're nearing the end of the hour, I'd like more
discussion to happen on github off of the call.
... Any other final comments on this one?
none
burn: That's the last of the PRs. So, is there anyone here that would be able to give us a test suite update?
<scribe> scribenick: stonematt
cwebber: haven't been focused on this recently. will review prioritization and update group next week
manu: hopefully will have it operational by TPAC
burn: please prioritize WG over CG
manu: makes plea for help
... we don't have to do all the Test Suite work, others can
help
burn: good bye!
[adjourned]