<inserted> scribe: manu

burn: As all of you know, we were busy last week, not much of an Agenda today other than covering the F2F meeting and figuring out what the plan for the next few weeks will be. Action items, status, etc.

cwebber2: One thing we did talk about was reviewing the space for what should be required of cryptographic suites and what should go into the test suite.

burn: There were items you mentioned at the F2F meeting, that you wanted time for.
... We didn't allocate that time for today, didn't see email from you, didn't want to put that on you.

cwebber2: We can do it next week or so.

stonematt: Let's keep it on the parking lot for today. Let's do a quick agenda review.

Chairs: Matt_Stone, Dan_Burnett

stonematt: We have introductions and Agenda review and review of F2F ... then we can bring in other items.
... We can do some of this on the fly today.
... Do we think we need the full hour for F2F or IIW review?

<Zakim> manu, you wanted to suggest time boxed to 30 minutes.

<dlongley> manu: Just to suggest timeboxing to 30 minutes. We may want to point people to the F2F minutes. Maybe we should point to what we minuted because it would give us more time.

<dlongley> manu: I would prefer to do next steps. New things, PRs, issues that are high priority and make sure we cover the stuff for Chris because he's working on test suite this week. He needs some questions answered before he can proceed.

burn: I don't think we should spend a lot of time reviewing what we did... IIW, but going through F2F meeting minutes - agreeing on action items would be a good use of time.

manu: +1 to burn

stonematt: Test Suite is important, let's see if we can make sure that happens on this call.

Introductions

stonematt: I saw Jarin pop in, he's a colleague in Pearson. We do introductions for newcomers -- would you mind giving us a few minutes for an intro?

Jarin: I work with Pearson, I've been with the organization for 18 years -- high stakes testing/credentialing division. I've led Acclaim / Open Badges for past 6-7 years, very excited about this, spoke w/ Manu when the group was getting spun up. very excited about individuals being in control of their credentials, sends a strong signal.
... Looking forward to helping out and being of assistance.

manu: Welcome Jarin! :)

stonematt: Anyone else that needs to introduce themselves?

Face-to-Face Review

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

<tzviya> http://www.w3.org/2018/04/06-vcwg-minutes.html

<liam> [ iiw session notes are linked to from http://iiw.idcommons.net/Main_Page]

Session Notes from IIW26: http://iiw.idcommons.net/IIW_26_Session_Notes

stonematt: How can we get action items out of this?

burn: Let's go through the minutes -- pick out action items, or do it offline -- up to you stonematt

<dlongley> manu: One thing we could do is, I know we have a list, we could talk about those and put them as action items in here today. Just so have a record.

<scribe> ACTION: Manu to write a section on Extensibility.

cwebber2: Do you want me to explain my action?
... This is issue number 72
... There are two issues here - discussion on current terms of use and what the scope there is... what delegation might be.

<stonematt> https://github.com/w3c/vc-data-model/issues/72

<scribe> ACTION: cwebber to propose a way forward wrt. delegation, VCs and OCAPs.

cwebber2: Terms of Use seems to be more about human policy (VC terms of Use) vs. machine-enforceable policy (OCAP)
... I have a good idea of how to write this up, just haven't gotten to it yet.

<scribe> ACTION: Manu to update "Verifiable Profile" to try and align with thinking from VC F2F.

DavidC: About "terms of use" -- always seen it as machine-enforceable terms of use... I would a Verifier to process it and enforce it.

cwebber2: What we have is policy-based -- correlation, storage, etc. A computer could check that, but enforcement of another agent doing those is something that would not be machine checked.

<dlongley> "terms of use" seems to go beyond just verification

cwebber2: maybe this is policy advisement to perform additional operations, not if VC is valid or not.

DavidC: I may provide a couple of examples where it would be advisable - restricted set ... verifier can check if they are in that restricted set... value of transaction, verifier can check to see if user wants to do is within terms of use.

cwebber2: if you can write that up and put it on issue, that would be great.

<Zakim> stonematt, you wanted to say this is a gap in UC not intent

<scribe> ACTION: DavidC to add examples of Terms of Use around Verifier-checkable ToUs.

stonematt: Ok, doesn't seem like there is a mismatch yet in understanding.
... This may be something that Joe, Tzviya, and DavidC could discuss.

<Zakim> manu, you wanted to note that miscommunication on this topic is tricky.

<dlongley> manu: Just wanted to point out that we continue to miscommunicate in small nuanced ways but significant ways on this subject. "Attenuate", for example means something very different to OCAP folks than it may mean to you.

<dlongley> manu: I think there continues to be a miscommunication -- there was one between Joe and Chris at the F2F, I think Matt just said "attenuation" and it meant something else. I think there is a subset of things that is machine enforceable and things that are not.

<dlongley> manu: I hope we're not miscommunicating, but I think we are, so we have to talk about this until we're sure we're not. I expect it to be worked out, but I expect this issue to be tricky to get through.

stonematt: We had defined one of our milestones to deal w/ Privacy and Terms of Use... we need to write use cases to refine that language.

cwebber2: I think that the use cases will help. I have a suspicion that part of this is that the terms of use are richer than attenuation and capabilities. My suspicion is that once we have examples, there is a strict domain for OCAP, but broader one for VCs.
... That may be good, but having those examples will help us w/ those boundaries.

DavidC: This isn't a new problem - obligations - in the policy, have to be machine enforced. Machine enforced policies - some are easily enforced - like firing off an email - other things are more difficult, "delete after 1 week". This is not a new problem, some ToU are easy to enforce, some are difficult to impossible.
... We are providing a general mechanism to include ToU... wording in the document for what is good practice, what is not good practice.

<cwebber2> I thihnk that's exactly it, you can put anything in terms of use, and it's a much more general mechanism... whereas caveats in ld-ocap *have to be* a much more strict, single concept

DavidC: The same principle applies for OCAPs.

manu: +1 cwebber2

stonematt: Without specifying implementation and solution - use cases/requirements is a good place to start. Then we can carve out in-scope / out of scope as a result. We can figure a lot of this stuff out wrt. market expectations.
... Let's write it down and then we'll have something we can dig our teeth into.

<dlongley> i think the main distinction should be between what happens at verification time and what may happen at some other time

stonematt: Any more discussion on this?

<DavidC> @dlongley good point

stonematt: We have another issue on critical properties.

<Zakim> manu, you wanted to note issue on critical properties.

<dlongley> manu: One of the things that came up during the F2F was general confusion about extensibility/data model. I wrote up a PR. David I don't know what your position is on it right now. We're adding a section on extensibility because that was a point of confusion.

<dlongley> manu: Now the question is what happens when the issuer adds a property where they know it's critical and the verifier should fail if they don't know anything about it. We should have a discussion about it in the group. Perhaps aligned with what X.509 crit field did.

<dlongley> manu: We're going to talk this through and it will result in a PR that adds something to the PR or that doesn't and it gets resolved in some way.

<dlongley> manu: I'm the person that will be taking an action on that once resolved by the people interested in that issue.

<scribe> ACTION: Manu to write up spec text on critical properties.

DavidC: I think they are intertwined, you dont need critical properties field if you don't have extensibility. it's when you start to add new stuff when people don't know what they are.
... Dave Longley and I have had some back and forth on this - one way to go is to say that /everything is critical/ - refuse to access anything that you don't understand. Critical allows you to add things, but allows you to ignore things.
... dlongley and I agreed that you need to understand certain things -- we're coming to a common viewpoint.

<dlongley> https://github.com/w3c/vc-data-model/issues/158

<dlongley> please participate in the issue if you have opinions

<dlongley> if you dont' have opinions, get some and participate in the issue :)

stonematt: We spent a lot of time last week on these issues.

<Zakim> manu, you wanted to track WebAuthn discussion.

WebAuthn discussion

<dlongley> manu: Something exciting happened at IIW that does affect VC stuff. We had a couple of joint sessions around DID-based authentication with the Web Authentication group at W3C. Wasn't expecting it but it did and one of the great things of IIW. The Web Authentication group spec just went to CR at W3C.

<dlongley> manu: We've been wanting to use hardware backed keys to work with VC over the Web and Web Authentication is all about doing hardware backed keys. The nice thing about hardware backed keys is that if you're using them software on your computer can't get access to key material, better security.

<tzviya> see also http://www.w3.org/2018/04/pressrelease-webauthn-fido2.html.en

<dlongley> manu: So we had discussions about how to get hardware backed keys to sign DID-auth or even issue VCs. I think this is a fairly good thing. The group should track this to a certain degree, don't lose sight of it. This sort of thing where two WG depend on each other's work is good, W3C likes to see that. It sounds like they are willing to modify the spec to work for us. Two light lifts in the spec could change so we need to get those suggestions in.

<dlongley> manu: Some of us are working to get hardware backed keys to sign VCs and that was exciting to see. Dave Longley and the Web Authn people will probably be the primary people collaborating. I'll monitor it as well.

<scribe> ACTION: dlongley to track WebAuthn integration w/ Verifiable Credentials.

<nage> Another interesting VC use case at IIW http://iiw.idcommons.net/User-Controlled_GDPR_Consent_Cookie

DavidC: Our implementation of Verifiable Credentials was FIDO-based, migrate to WebAuthn and IETF token binding. Those two together would give you a way to send data between issuers/holders and verifiers.

stonematt: Do we expect the data model spec to change based on this? Is this crypto suite implementation?

dlongley: I expect that the only changes we would see would be around Verifiable Profiles since we're using those to do authentication. it really depends how much we're able to get into the WebAuthn spec. That part shouldn't affect the Verifiable Credentials data models. We have some stuff going on about Verifiable Profiles, there may be some changes there. SO, it's something to keep in mind.
... We want to use WebAuthn in the space, what happens there may change what a Verifiable Profile looks like.

<Zakim> manu, you wanted to note Verifiable Profile.

<dlongley> manu: To follow on there, we also put an action item in for myself a while ago in the chat. We had a great discussion around Verifiable Profile, David Chadwick spotted a difference between presenter and holder came up. We believe we have a unified way to approach it based on the F2F. I'm hand waving a bit, but we think we can harmonize the way the Sovrin approach does presentations of proofs, the way other more traditional digital signatures work, and the

<dlongley> way the FIDO authn stuff works, we believe we can harmonize all those things in what we're calling today the Verifiable Profile.

<dlongley> manu: It may change into a "Verifiable Presentation".

<dlongley> manu: I put an action item on myself to harmonize those things and run it by Nathan, David Chadwick, Web Authn people, etc. to pull those three use cases together.

<nage> +1 to making a space for credentials and presentations of credentials distinct (it helps a lot with ZKP protocols)

<dlongley> manu: So that's good news on that front.

stonematt: One question to the group -- skimming through minutes - discussion about what's explicit and what's implied -- observation about lots in this space where "JSON-LD takes care of that" -- implied relationship that's not explicit. Is that a new topic?
... Or is that about extensibility

<dlongley> manu: They are semi-related. Extensibility section will deal with some of that. But not all of it. There has been confusion around the ID property around what it does and what it means. We do need to clarify that outside of the extensibility section. I don't know if we actually capture this in an issue.

<dlongley> +1 to more text on graph model and identifying nodes in it

<stonematt> ACTION: Matt Stone to raise an issue that deals directly with the definition of 'ID' in the datamodel spec.

Test Suite

stonematt: cwebber2, would you mind leading this section?

cwebber2: Currently, the test suite has an issuer and a verifier and a set of documents which the issuer will issue, which involves signing, and then the verifier ensures that that's valid.

<DavidC> @manu issue #120 about IDs

cwebber2: Some of the stuff that's tested is stuff like "is this a date" or "is this the right type"... part of my question is "is this all we want to do?"
... A large portion of these items... went through all MAYs and MUST - some of them are testable, a lot of them -- I can't figure out how I could test them.
... "Is there a cryptographic suite"... "may be a proof purpose"... etc. And then boring dates, etc.

<dlongley> it would be good to get a specific list of MAYs and MUSTs that can be tested or not

cwebber2: expires is a good one that's testable. it gets a bit trickier when we get to stuff like "holders MUST receive and trust through agent"... MUSTs are things about the policy between the parties. Holders MUST control, etc.

<cwebber2> http://sebsauvage.net/paste/?65a84a10507792b7#myl/MlE8blqe/QS/rr2jIn5YQI6N93WRfOrGWybRFKw=

<dlongley> it may be we need to remove untestable MAYs and MUSTs or change the language to remove MAY/MUST.

cwebber2: Which of these things should I be writing tests for, are there other SHOULDS/MUSTs policy of application, do we need and can we even have tests for those?
... Terms of Use and Evidence... some terms of use
... We have type checks, we know test suite can issue things, verifier can issue things, what else is critical?

<cwebber2> http://sebsauvage.net/paste/?65a84a10507792b7#myl/MlE8blqe/QS/rr2jIn5YQI6N93WRfOrGWybRFKw=

burn: One of the comments - language like this - when you find something that's not testable, the way its written is trying to put a restriction on a user rather than on something the spec itself has. For example, this is a data model spec, we can't do much with what a holder must do / subject must do.

<cwebber2> oh maybe it did paste :)

burn: We can say that certain constructs are possible. One way to figure out who you're putting the requirement on is to think about the "or else" case... sometimes you can reword to put requirement on the testable entity, or only testable entity is something we don't control as part of out testing process, then it is something that has to come out of the spec as a normative statement.

<dlongley> +1 to burn

burn: wrt. to MAYs and SHOULDs, they are not ignorable. Let's be careful there.

<dlongley> +1

bigbluehat: I wrote tests for the Web Annotation WG, with help of Shane.
... Rewording spec is what might be needed, a MUST/MAY/SHOULD is often initially in drafts written for a human being, nontechnical things to be tested, if they exist, they need some testable regiment attached to it.

<burn> Agree that only testable assertions can remain in the spec at the end

bigbluehat: Which relates to why only the MUSTs matter. The MAYs don't have to be tested at all. The SHOULDs should be tested. In order to get W3C gold star, you have to do the MUSTs. Your implementers will have to do the MUSTs, but if they want more green checks they will do SHOULDs. If you want interop around something, you have to do it as a MUST.
... If you do a MAY, someone may implement it, but they may not. Your implementers are only ALL going to do the MUSTs.

<burn> Every SHOULD needs to have an 'unless' (according to IETF, who developed the RFC language for this)

cwebber2: So, all normative requirements are equal, but some are more equal than others.

burn: We can debate that over beer, but start w/ MUSTs.

DavidC: For termsOfUse, none of it can be tested. But expiry date can be tested.
... Important that we specify what the extensible bits are, and they won't be tested.

<burn> This is a longer topic, Chris, but start by figuring out who you are trying to put a requirement on and rewrite to only put that requirement on a testable entity

cwebber2: I should probably write up all of the tests and send them to the mailing lists. Break out all of normative statements about what is testable, not testable... then maybe CG can help w/ what can't be testable? Work that out on mailing list/GH issue.

<bigbluehat> I will add that your test tools can and SHOULD cry loudly about SHOULDs and MAYs...but if you *really* *really* want them implemented...make them MUSTs

<dlongley> issue

<bigbluehat> +1

<dlongley> manu: I think we should have a spreadsheet with all of these in there. It will be too hard to discuss on a mailing list.

<stonematt> ACTION: cwebber2 make a spreadsheet in gSheets to track test cases

<burn> spreadsheet to track, create issue for each problem

cwebber2: I'll start a spreadsheet and post it to mailing list/issue. Maybe open an issue and link to spreadsheet.

<burn> +1

<dlongley> issue + spreadsheet sounds good to me

<stonematt> +1

cwebber2: I'll work on that after CCG call.

stonematt: Ok, that's the call for today.

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: i/rrsagent, draft minutes/scribe: manu
Succeeded: s/raise an issue/Matt Stone to raise an issue/
Succeeded: s/should/SHOULD/
Present: Dan_Burnett Chris_Webber Ted_Thibodeau Gregg_Kellogg Tzviya_Siegman Manu_Sporny Matt_Stone Dave_Longley Liam_Quin Jarin_Schmidt Benjamin_Young Nathan_George David_Chadwick David_Lehn
Found Scribe: manu
Inferring ScribeNick: manu
Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018Apr/0014.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: cwebber cwebber2 davidc dlongley manu matt stone

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.)