<stonematt> Chair: Matt Stone

<scribe> scribenick: dlongley

stonematt: Anything missing in the agenda that we should cover other changes?

Liam: I have a brief addition from mail this morning, we should discuss TPAC.

stonematt: Ok, is that something we need on the agenda today?

liam: We should talk about it today briefly because the 27th of April the registration for chairs is closing.

stonematt: Ok, let's do five minutes on that after introductions.
... Anyone new on the call?

Introductions

Yancy: This is my first time on the call. I'm Yancy Ribbons, I'm a develop on the Acclaim team. I've been on the Acclaim team for about 3-4 years now. I've been very interested in the developments around DIDs and I know Verifiable Claims is linked to that.
... So I'm exploring and hoping to learn more about how Verifiable Claims works together. I'm also transitioning over to Credly as part of the Acclaim/Credly merger. That's my short intro.

stonematt: Thanks, welcome to the group!
... Any other intros?
... Ok, moving onto TPAC discussion.

TPAC Discussion

<stonematt> +1 to go.

liam: The main question is whether we're going. TPAC is a W3C meeting we hold in September/October of each year. Pretty much all the WG meet at the same time in the same facility. We're being asked if we'll go again this year.

<manu> +1 to go

liam: 22nd Oct-26th Oct. It's in Lyon in France.

stonematt: For reference, last year when we did this, the plenary breakouts where 2-3 days of live discussion. It took this group some months to get ready to go (prep work). When we raise our hands to go that's what we're signing up for.

<liam> [ some more info for chairs - https://www.w3.org/2002/09/wbs/34786/ChairsTPAC2018/]

stonematt: Secondly, on this, by the time October rolls around we should get close to CR. There will be a deadline about making some actions for the WG. That's worth putting into our collective consciousness as we move into the summer. Quite a lot of work to do to get closure on these topics and move the spec forward.

liam: The main advantage of registering early for TPAC is you get to say which days you meet on. Other than that the group could say we want to go and change our mind later and that's not a problem. Deciding after the summer means there may be no room for us.
... Usually better to just say you want to go.

manu: Just to mention that we should definitely go. It's usually not a good sign if active WG aren't at TPAC. It's also a great opportunity for us to go around and collaborate with other WGs and give W3C members an update on the status of our work and a bunch of other good things. It's a good networking activity.
... Around other things we are interested in pushing like DIDs and things of that nature. I would be very concerned if we would not be going.

<bigbluehat> +1 to being at TPAC--it's a uniquely valuable "moment" in ever calendar year

<nage> IIW 27 is on October 23-25, in case that affects whether folks have conflicts

stonematt: If there are no objections I'm +1 to go and think it's important.

<DavidC> +1 to TPAC

stonematt: I'd still opt for TPAC given the role and meeting we're in. :)

liam: We should commit. If there's something we need to do as chairs you and I can work online to make that happen.
... I pasted a link for chairs into IRC, but that's fine.

Action Item Review

stonematt: We'll try and cut this short so we have time to get into the test suite which is next.
... There's a link in the agenda for action items.

<stonematt> link in agenda for action Items: https://goo.gl/V4XTBT

stonematt: This is a quick summary of action items out of last week's meeting which was pretty full. We started pulling actions out of the F2F meeting the week prior. I know a few of these were completed and some more since last week. Take a minute and just run through these quick and we can mark those that are done and figure out how to approach others.
... We had an action here from Chris to propose a way forward with regard to delegation, VCs+OCaps. We have an issue for it so the action is taken care of. Is that a reasonable way to dispose of this action in this doc, let the issue lead?

+1

<cwebber2> +1

stonematt: So if we take an action and we can track it somewhere else I'd like to get it off the list.
... Chris has the spreadsheet for test cases so I think that's taken care of.
... David Chadwick had an action to make examples for terms of use around verifier-checkable TOUs.
... David, we had a really good discussion about this in the focal use cases last week and we might have the beginning of that done so I left it open.

DavidC: I apologize I've been busy this week but I should be freed up a bit now.

stonematt: Ok, we should have a pattern to work from based on the use cases from last week.
... This tricky action item for Dave Longley to track WebAuthn w/VCs.

<manu> stonematt: How do we know when this is complete? Or is this a reminder?

<manu> dlongley: I'll add something there... work is progressing on that one.

<manu> dlongley: I'll raise an issue on WebAuthn on the issue tracker.

stonematt: Updating the Verifiable Profile from F2F thinking -- do we have a PR, manu?

manu: Not yet. I thought there was an issue ... we have a clear path forward based on the discussion at the F2F. David Chadwick's issue 107 kinda sorta is tracking this.
... In any case, we should raise an issue if one isn't there, that's definitely the next change I need to do the PR for. I have a clear idea for what the spec text for that should be. That's in progress. Trying to figure out if David Chadwick's issue is the same or not, if not I'll add one.
... Next up is to write a section on extensibility, there's a PR on that. There was some back and forth between Dave Longley and David Chadwick -- so the question is if David Chadwick is ok with the result of that discussion so we can proceed.
... Then I need to update the PR to reflect Joe Andrieu's suggested changes.
... David, are you comfortable with the direction that PR is going in or something else?

DavidC: I just posted a comment to that at the start of the meeting.

stonematt: I want to interrupt ... sorry, I don't want to start a discussion just want to track actions.
... We've got the PR for extensibility so let the discussion happen there, we can take it off the list.
... That fair?

manu: Yes.

stonematt: We can discuss open issues in the meeting later if we have some time and need to.
... I still have one action item on definition of `id` in the data model spec. I'll do that before next week.

DavidC: Is your issue a different one from the issue I raised on `id`?

stonematt: What issue number?

DavidC: 120, `id` is not differentiated sufficiently.

stonematt: It might be related to that.
... I'll compare to that one and see if it's the same or different and move forward.

DavidC: Also 105, which is about identifiers as well.

https://github.com/w3c/vc-data-model/issues/120

https://github.com/w3c/vc-data-model/issues/105

stonematt: Ok, that's the actions that came out of last week.
... Any actions that were missed?

Test Suite Discussion

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

stonematt: Handing the floor to Chris.

<cwebber2> https://github.com/w3c/vc-data-model/issues/161

<cwebber2> https://docs.google.com/spreadsheets/d/1MCIZghhT5xCTnBpqDMpeCqc0zBS2Lgwfoi0tONijZOQ/edit#gid=389045348

cwebber2: I wrote up an issue about the test suite and making sure we get the requirements down. I linked the spreadsheet to it. Everyone is welcome to contribute.
... I also linked to Manu's feedback as a separate sheet on there.
... A lot of these had comments that gave a path forward. Some of them are a bit more challenging in that they are ... there is a large chunk in the middle that is crossed out because some of them are not testable in terms of the test suite.
... If you look at line 17 and Manu's comments. Manu says that the text should be rewritten as not MUST/SHOULD, etc. The behavior is important for what we'd like but aren't required for conformance because not testable in a test suite.
... So a number in the middle there that are that way.
... I don't know who all got a chance to look at this in detail other than myself and Manu. I would guess for most of these, most have a response on how to move forward on them, maybe before getting into specific ones it would be good to get people's feedback, people on the queue.

<manu> Talking about this section right now: https://w3c.github.io/vc-data-model/#use-cases-and-requirements

manu: I just wanted to point to a section on the spec that might let us knock out a number of these test items. As Chris mentioned, there are a number of things that are not testable but we have a bunch of MUSTs/SHOULDs in the spec. Specifically the link in IRC.
... We have a big chunk of stuff in there that say holders MUST and SHOULD, etc. These are MUST and SHOULD that apply to ecosystem requirements than they do to implementations. We put that in the spec to protect the group. It's for the mission of the group.

<Zakim> manu, you wanted to explain why OOB stuff is struck through.

manu: We were making strong distinctions between, for example, how OpenIdConnect does stuff with identity providers and so on. Today that ecosystem is much more accepted as a valid thing. Many of these MUSTs and SHOULDs are from section 1.3 which have more to do with the ecosystem.

<stonematt> what does OOB stand for?

<cwebber2> out of band

manu: And ensuring a certain structure and architecture and less to do with the technical implementation of a processor. That said, we should not remove from the spec. These MUSTs and SHOULDs are use case and requirement MUSTs and SHOULDs not implementation -- need a PR for that.
... If someone else has a way to handle that differently it's welcome, we may be unique given the political environment at the time.

DavidC: I think it would be very good if the document somewhere says something like "If a verifier gets a credential where something is wrong, then the verifier must throw away the credential." Because that's testable. We don't seem to have something like that.
... The second point I'd like to make was about revocation. I thought our data model that allowed for short lived credentials that would never be revoked but we have "VC must be revoked by the issuer" for #4 which seems to rule out shortlived credentials that aren't revoked.

<manu> I like mattstone's suggestion

stonematt: While you were describing the ecosystem, Manu, rather than thinking about holders MUST and SHOULD and instead say "it's the holder's responsibility to do X" if it's an action they are taking out of band rather than something we can test. That may make the spec text more clear that it's happening elsewhere but there's important tasks for the roles to take on.

+1

<manu> +1

<cwebber2> +1

stonematt: Going back to the trust model in the use cases and saying it's the responsibility of various roles to do these various things.

<TallTed> +1

<nage> +1 making the roles clear helps implementers

<Zakim> manu, you wanted to note that we have "negative tests" and to say we do support short-lived and should fix that.

manu: I like that a lot and it makes it very easy to understand how to do that PR.

<manu> ACTION: Manu to reword section 1.3 to remove MUST/SHOULDs and instead talk about ecosystem expectations with roles and responsibilities.

manu: To respond to David Chadwick, we do have negative tests where the issuer or verifier to throw an exception. And that may be -- I forget exactly what you said, but for some reason I thought the negative exceptions would take care of that item.
... The other thing you said was about short lived credentials -- and we certainly should support those and we have problematic wording there. I thought that the language was that "if a field exists you must process it" (such as a revocation list) but at the same time if that field doesn't exist, then you've got an unrevocable credential. We should certainly support what you said..
... If we don't, if that MUST is problematic, we should change it.

DavidC: I think it's probably that S4 needs an "if" ... "if the status indicates that the credential's status can be checked then it must be".

manu: Yup.

<Zakim> cwebber, you wanted to ask about specifying revocation method for #8

cwebber2: There are some specific line items I'd like to discuss starting with line item 8. "credentialStatus"... with this one, I think we'd need to have a specific revocation method that we'd have at least written out enough to test in the test suite. We can't test all of them, but if we can define one, then we can check for "this one" at least.
... And we can make sure the behavior of checking that has been put in place. Likewise with terms of use. Some terms of use are always going to be out of band. Like "don't share this with anyone else". There's no way to know that in the system.
... You don't have complete view of the universe. I believe David Chadwick had an idea on things that were checkable.
... I could use help, David, if you have an idea on what those specifically could be it would be helpful if you could write it up so I could that in.

DavidC: We've already agreed that there would be another document with things like this kept by W3C that's a registry.
... In which case we can start a couple of entries in these registries and those are the ones that tests can be written for.
... I'll write something up.

<cwebber2> maybe... :)

stonematt: If I'm a holder and I give you a credential and say don't verify. That means no one else can verify that after you -- if the verifier should cache it and pass it on, that verification should fail.

<manu> yes, maybe :)

stonematt: That could be the enforcement of the terms of use.
... It couldn't be read by someone else somehow.

<manu> not couldn't... shouldn't be accepted :)

<Zakim> stonematt, you wanted to say OOB terms of use check

DavidC: There is something Manu and I discussed earlier and that's on risk management. If the verifier wants to take the risk on themselves, they can, at their own expense, accept a credential with terms of use excluding them.
... A real life example is a Safeway coupon that says only to be presented at Safeway. Then I go to Tescos and I give them coupon. They may accept it and give me the benefit.
... That's a real life situation.

<manu> That's a good use case -- competitor discount matching.

DavidC: Somehow we have to word it in the document.
... Manu has a sentence about risk profile. Maybe we should remove that sentence.

<Zakim> manu, you wanted to note we have https://w3c-ccg.github.io/vc-status-registry/ and https://w3c-ccg.github.io/vc-csl2017/

<cwebber2> my fault, I brought up ToS *and* credentialStatus

manu: I feel like the topic shifted at some point. I thought we were talking about number 8. I want to elaborate on that. "credentialStatus" and how to test it. We do have a registry as David Chadwick pointed out.

<manu> Credential Status registry: https://w3c-ccg.github.io/vc-status-registry/

<stonematt> ACTION: stone to open discussion w/ DavidC re: enforcing the Terms of Use in the use cases.

manu: We have a credential status list, which is published as a document at a URL and then we have a credential status blockchain that lets you put status registries on blockchains. The difficulty is that we can't say anything normatively unless these other specs are going through the WG. And that adds complexity so I don't recommend it. We can also put non-normative tests in and check those.

<cwebber2> but does that mean that the data model doc would also become non-normative in that spectext?

manu: Status checking mechanisms are non-normative but there's a slot in the data model and we have to test that in some way.

<manu> Credential Status List 2017: https://w3c-ccg.github.io/vc-csl2017/

manu: If we make that a non-normative test then this becomes testable.
... We do have a way of testing this but should make it non-normative.

<Zakim> cwebber, you wanted to ask about whether tests that hit the network are acceptable

stonematt: I took an action to open a discussion on use cases. Go ahead, David.

DavidC: Just to respond to Manu about the status. Could it not be a mandatory test that guarantees failure? It says you must check the revocation status if you understand it. But put in a test where the code is guaranteed to not be understood because it is not defined and the credential must be rejected.

manu: Yes, we should do that.
... I think there's a sub thread here around non-normative testing. The only thing we're doing here is a data model but need to make sure it works in reality. So more REC things must exist to test normatively so we are testing non-normatively.

<cwebber2> yes exactly

<Zakim> manu, you wanted to talk about "non-normative tests".

manu: So to do proper testing we need to make sure larger ecosystem is working. We will be forced to create the test suite so we test the data model aspects of it, but it does not give us assurance that we've built a data model that is extensible and useful in the ways -- companies that need it to be able to prove that it's extensible and works at that level.
... So we can have core normative tests for the data model and then some non-normative tests that prove that extensibility work. They've been demonstrated to work with at least one extension but not put them in the critical path. When all tests are done we can guarantee interop beyond what the specification is mentioning.
... So we can prove interop on the signature mechanisms, on status/revocation, terms of use, so on.
... As long as can at least that those things work, even if non-normative, people can understand the data model truly is interoperable.

cwebber2: That's great and I agree with everything Manu just said. The other issue that has come up in the test suite document a few times is that...
... Number 12-14 are examples that are about testing from a live connection. 12 is verifying signatures -- that the public key is available. We could do this by having the public key be a local file, but I think that's not great. And likewise for 13-14 even more so I think ... having that be local, we could have these applications test things on the local filesystem, but that's not how it will run in the real world.
... One suggestion made in 14 ... "it's pretty clear to me that we should support hitting github.io site."
... I wonder if people are ok in general with a few us that check connections or check the existence of some document ... whether or not putting up a static set of files that we host somewhere is acceptable to the group.

DavidC: As I pointed out in one of my comments, this is a known DDoS attack on X.509 with revocation lists. What the software providers are doing is breaking the model and asking the user if they want to proceed or not. Google has stopped using revocation lists because it's broken. I would prefer we don't introduce mandatory network connections.
... You shouldn't need to have to use the network to validate and if you can't you have to throw it away. Software developers ask the user when they can't access the network and of course they always proceed and things are broken.

cwebber2: Small response to that -- I think we should avoid getting too much into the specifics of what ... what specific methods, we have an extensible model so we know there are multiple methods that can be established, this is about more than just revocation, also public keys, I'm hesitant to get into which methods are effective and which aren't.

<Zakim> manu, you wanted to say that we should serve up files on a domain... or localhost? and to say "you have to have everything on hand" is problematic, and so is asking the user.

Manu: So, we could serve files... as Chris said we should separate how to implement the test suite from what mechanisms are the best from a privacy/correlatability perspective, the latter being a long complicated conversation and the former about getting to candidate REC.
... Just talking about the test suite, we could put it on github, static files from there. Or ask testing people to serve files off of localhost. Having done this before multiple times in different WG, the WG just opts to putting up a static site that just serves the files. Everytime we've done test suite drivers where implementers have to setup their own driver this way it's not well received.
... They may still do it, but it's not easy. Easiest to just serve it up off github, with downside of domain going away, but we can update the test suite then.
... David mentioned that if you don't have everything on hand it's a problem and asking the user is a great example of the wrong thing to do. So saying that if you can't fetch from the network then you need to fail and maybe we should put a MUST or SHOULD in the spec. I'm fine with that.
... The problem is that we don't want to pass value judgments this deep in the spec. My expectation is that Nathan will talk about correlation and downloading things off the network and he's right. But we need to support URLs, HTTPS URLs, being identifier agnostic and so on -- while poking and proding people to avoid certain mechanisms.
... Spec needs to be balanced, saying you have to have everything on hand may be unrealistic even in blockchain scenarios. May be examples where it's perfectly fine to do so, so we shouldn't prevent that usage.

<Zakim> nage, you wanted to ask if that does not bias the spec towards a particular retrieval or validation protocol

nage: I regret that I didn't hear what Manu said. I like the approach of serving up static files and keeping the test suite as much as possible about the data model. Each protocol/etc will have different ideas about how things are done. While we do want to test that for interop amongst the protocols, this spec is about data model. Venturing too far into protocol would bring up discussions about unspecified work.
... That might lead to a lot of problems about standardizing the data model that we don't have to address at this point. Talking about key resolution or look ups for revocation or whether you trust a credential/web of trust, etc. We'll get into trouble.
... So we should get out of band discussions on how to deal with this tricky issue. Sovrin folks are trying to figure out how to fit in because of particulars in the protocol but what we need to test is the data model.

stonematt: Any actions related to that?

<manu> Nathan, I also mentioned that we shouldn't say certain identifiers are good and others are bad for the test suite... we should just figure out how to test things. Perhaps we have "link resolvers"?

nage: Chris and I will take an action item to figure out how we can sync up. That may help answer some of these protocol vs. data model because Sovrin's protocol is quite different from others.
... That will force us to resolve some of these issues.

cwebber2: We have enough info to make some movement.

<stonematt> ACTION: Nathan and Chris to connect on how to integrate in the Test Suite

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/Yancy: This/Topic: Introductions
Succeeded: s/ecosystem expectations/ecosystem expectations with roles and responsibilities/
Succeeded: s/prrvent/prevent/
Present: Matt_Stone Chris_Webber Manu_Sporny Dave_Longley Allen_Brown Liam_Quin Benjamin_Young Nathan_George David_Chadwick Yancy_Ribbens Ted_Thibodeau David_Lehn Tzviya_Siegman
Regrets: Joe_Andrieu Dan_Burnett
Found ScribeNick: dlongley
Inferring Scribes: dlongley
Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018Apr/0019.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: chris manu nathan 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.)