<burn> Agenda: Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018May/0011.html

<JoeAndrieu> my audio connection (via zoom) is failing, although it shows me the room

<agropper> My audio is via WebEx

<JoeAndrieu> (I meant WebEx)

<JoeAndrieu> Audio just woke up for me. For no apparent reason

<stonematt> nice!

<JoeAndrieu> brutal

<cwebber> irc only meeting! ;)

<JoeAndrieu> Ommmmmm

<scribe> scribe: manu

<stonematt> https://lists.w3.org/Archives/Public/public-vc-wg/2018May/0011.html

stonematt reviews the Agenda.

stonematt: Looking to make progress on Subject != Holder... terms of use - use cases scope... and updates or changes to Agenda?

Introductions / Re-Introductions

markus_sabadello: Been contributing to DIDs and VCs for a while now, new on this WG because I wasn't a W3C Member.
... I've been sponsored by a local university in Vienna, looking forward to participating.

stonematt: Thank you!

Action Item Review

<stonematt> https://goo.gl/V4XTBT

<scribe> Chair: Matt_Stone

stonematt: We have an action for Chris and Nathan to work on test suite.
... any updates from anyone else

<cwebber> So nage and I started an email thread where we were talking about getting json mockups of what the VCs Sovrin intends to issue

DavicC: Doing some work on PRs... ToS... haven't yet done the diagram yet.

<cwebber> nage passed it over to Daniel Bluhm to give examples, but

<cwebber> I think they need help

stonematt: We'll close "David to update examples in his branch and work to pull in PR169" and track it in the PR.

<nage> cwebber and I are communicating, and Daniel Bluhm is working on integrating the Indy reference agent into the test suite. The Sovrin community is also starting work on the PRs to the vc-data-model repo, watch the sovrin-foundation github fork to follow what is going on there.

<nage> +1 to closing out the spreadsheet action item and tracking it through the PRs and other repos

<nage> cwebber: yes, Daniel needs some support there, the reference agent isn't sufficient to meet the test suite needs yet

<dlongley> manu: Allen Brown sent in a series of spec review comments which are fantastic. But it's going to take me a while to get through them. Total time is like 8 hours of spec editing.

<dlongley> manu: To respond to his comments.

<dlongley> manu: So there are two PRs in right now. One is outstanding and needs review, please review so we can pull it in.

Allen Brown's review comments -- https://github.com/w3c/vc-data-model/issues/175

<dlongley> manu: The other one is a bunch of editorial suggestions to the spec.

<dlongley> manu: Again, I'm going through every statement one by one and determining if editorial changes need to be applied to the spec, about 40% of the way through, will take some time.

<Zakim> manu, you wanted to note progress on Allen Brown's type stuff and to note progress on Allen Brown's spec review.

<dlongley> manu: If there's anyone else working on PRs, a side effect is that ... the review comments touch the entire spec. If you work on a PR over the next week or two we'll have to resolve conflicts. That's a heads up to people working on PRs.

<dlongley> manu: I expect many of the comments are editorial in nature, they are clarifications to the existing spec, I haven't seen anything that changes the core data model yet. Just a heads up to everyone seeing those changes and please say if you think there's a substantiative change, that's not the intent.

<dlongley> manu: So lots of changes coming in but should be all editorial.

<dlongley> stonematt: Is there a benefit to getting the other PRs in before pulling your changes in? Any guidance on the order?

<dlongley> manu: A bit too late for that, we'll just have to deal with it. The other thing I could do is just block waiting for other PRs to clear. I'm going to probably have to put in PRs to the existing PRs to get things to merge nicely. It will be a mess. Getting reviews on the spec do this. When you have full reviews of the spec they are great but they generate a set of PRs that are large.

<dlongley> stonematt: Are you pulling into PR 179? All collected there?

<dlongley> manu: Yes. And 179 builds on top of PR 177.

<dlongley> manu: We're going to be asking people to clear 177 and 179, please review, all editorial, should not be controversial. Unless we get those pulled into the spec it will block the other PRs coming down the pipeline.

<dlongley> stonematt: Ok.

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

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

stonematt: Credentials MUST always be verifiable - should we assign this to DavidC

DavicC: Fundamentally, Manu and I have differing views on this.

manu: +1 to that, it needs someone else to lead the discussion.

DavicC: Let's give it 5 minutes to get somewhere

stonematt: Let's time box this discussion, pretty fundamental thing - give ourselves 5-10 minutes.
... Can you quickly introduce the issue?

DavicC: We do not trust the user, but we trust the issuer and the verifier is receiving something through an untrusted channel... so credentials should always be verifiable.
... There is no room to have unverifiable credentials -- unverifiable credentials can be expressed, gave an example of a use case, and I dispute that use case.

<Zakim> manu, you wanted to give it some air time. and to

<dlongley> manu: Yes, it's a good summary. I think the only thing that we can talk about is whether this set of use cases where you don't have a proof on the VC is a set of use cases we want to support.

<cwebber> I'm dropping off the audio portion of this call because I can't actually hear anything

<cwebber> irc

<dlongley> manu: I think that's the crux of the disagreement is whether or not you want to express data as a credential and leave off the proof for some reason. Any kind of form submission on the Web fits that use case.

DavicC: What I'm arguing is -- if we want to support the unverifiable credential use case -- we have to change the data model and trust model, and introduce the concept of a "trusted source" and you can connect to a trusted source via a trusted source, and get an unverifiable credential. That is not in our current model. If we wanted to support that use case, we need to change our trust model.

stonematt: Is this basically signature vs. not?

DavicC: If we don't have a signature, you have no way of knowing whether its true or not... you can have false claims, we don't want to open ourselves up to that.

tzviya: Isn't the point of the whole data model that it's verifiable.

<dlongley> manu: When you go and sign up for website, you give email address, potentially occupation, whatever, etc. If you wanted to mark up that information you could use the same data model that is semantically rich. Right now it's just the bespoke thing that you submit. We could reuse the data model here and people could find that useful.

<dlongley> manu: We're the VC WG but that doesn't meant we can't create something that's useful without the verifiable parts.

<dlongley> manu: When you log into a website and sent information that's over a trusted channel (typically). If you were to deliver a credential, not a verifiable one, websites might find that useful. If you look at schema.org and the type of information they express you could put that into a credential without a signature on it. That could be useful

<dlongley> manu: That's not the primary thing this group is trying to do, but if we put strong language in the spec that would take those use cases off the table.

<dlongley> DavidC: I say that's perfectly ok, but we have to change the trust model.

DavicC: We need to update the trust model to say that.

<dlongley> DavidC: If we want to accept unverifiable credentials, but they are still trusted because you trust the user and you have a trusted channel.

dlongley: Yeah, just wanted to say that this debate might be easier if we had specific spec text wrt. changes. I don't think there are a lot of changes here... you could use the data model to represent information and send it over a trusted channel. We can say how not having a proof can still be trusted.

<stonematt> q_

<Zakim> dlongley, you wanted to ask what the actual spec text differences would be

DavicC: I think that's a fair way forward, then.

<scribe> ACTION: Manu to update trust model to support "UnverifiableCredentials".

PR Reviews

stonematt: We're going to hold on 177 and 179 PRs... waiting on Manu to finish those up.
... 169 is ongoing... what's left for Subject != Holder, DavidC?

DavicC: I've made the requested changes, please take a look.

stonematt: Can you provide some feedback, Manu, Chris?

manu: Yes, will review... thought I had.

stonematt: Just close the loop on that one.
... PR 146 - Terms of Use.

DavicC: There is one issue, not editorial -- when you specify an `id` of a particular `type`, should the first type be the type or any other type.
... We shouldn't have examples of types for some and not examples for others... for specific types.

<Zakim> manu, you wanted to note types are sets not lists.

<dlongley> manu: There's a discussion with Allen Brown around whether you must put a type in for everything. I think the problem there is that there are cases where you don't want to or can't do that. You either don't know the type or you don't want to specify the type for some internal reason.

<stonematt> manu refers to email discussion with allen brown regarding the cases where Type is unknown, unknowable, or withheld

DavicC: The point I was making was not whether everything should have a type or not... for specific properties, there should be a fixed type. You've done that for Credential and Presentation, there should be TermsOfUse and then anything else in the list.

<JoeAndrieu> My audio has completely failed.

stonematt: we're slowly moving to ToS...
... so, maybe we shift the discussion that way?

Terms of Use

stonematt: Want to discuss terms of use and scope
... I've been working with Joe and Tzviya to create some use cases and think of ways to bring terms of use into the discussion.
... What are the boundaries of terms of use? Some of the ideas I came up with have to do with data model / protocol -- how would we express some things? Also looked at Charter, looked at Terms of Use in Charter, so have latitude in the way we address it.
... I'm worried that things like OCAP are young and premature, we shouldn't adopt entirely, that work is going on in W3C CCG. What do we include if we try to narrow the scope in that way?

DavicC: I tried to address it in the new text... each term of use compised its type, precise contents is determined by specific terms of use type definition. Other standards can specify Terms of Use types and contents. Contents are not defined, there must be a type, the type specifies what other types are.

<Zakim> manu, you wanted to agree with DavidC... kinda.

<dlongley> manu: I like that. I think it's the appropriate level of specifying what it's for and then delegating exactly what goes in there to other specifications.

<dlongley> manu: I'm going to nitpick on the type though. The question around Terms of Use and type. If another specification is going to specify its own type and say the type of terms of use it is, then I wonder if having a type "TermsOfUse" does us any good. What piece of code is going to create an "if" statement around that?

<dlongley> manu: If "type === TermsOfUse" then what? I think it won't do anything.

<dlongley> manu: That's a nitpick. That is trying to talk about the previous question that David Chadwick asked. As a general principle the text he proposed is fine and the scoping Matt outlined is good to have.

stonematt: That suggests that the two PRs wrt. ToS are ready or nearly ready to pull in.

DavicC: 170 has supersceded 146... so let's close 146.

<stonematt> ACTION: DavidC remove/squash PR146 - it's replaced by 170

<dlongley> manu: David, I'm sorry, I remembered what happened here. I did ask for a couple of modifications to 170 and haven't seen a response from you just yet.

<dlongley> manu: I did a number of comments on 170... I have nine other review comments at the very bottom that haven't been addressed yet. Nothing major.

<dlongley> manu: I didn't click the submit full review button :)

stonematt: We're 3 minutes out... let's stop for the day.

<dlongley> DavicC: I'll look once you submit. :)

<stonematt> good bye all

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/FWIW, I didn't hear Nate either.//
Succeeded: s/lol//
Succeeded: s/I'm not trying to talk at the moment//
Succeeded: s/it're placed/it's replaced/
Present: Chris_Webber Matt_Stone Manu_Sporny Nathan_George Adrian_Gropper David_Ezell David_Chadwick Allen_Brown Tzviya_Siegman Benjamin_Young Joe_Andrieu tzviya Liam_Quin
Found Scribe: manu
Inferring ScribeNick: manu
Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018May/0011.html

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: davidc manu

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)