<scribe> scribe: manu

Chairs look for a scribe...

<stonematt> https://lists.w3.org/Archives/Public/public-vc-wg/2019Aug/0012.html

stonematt: On the Agenda today, start w/ PRs, issues, test suite, implementation guide, finish with use cases document.

burn: Do we need a further discussion on UK Government topic?

DavdC: This isn't needed until September, we might get the real urgent stuff out of the way.
... Then we could spend some time in Aug/Sep on UK Government response.

stonematt: Ok, we can do a touch base towards latter part of meeting.
... If there is anything to add, we will bring this up.

<Zakim> Justin_R, you wanted to ask about the nature of the response

Justin_R: Is the nature of this response going to be one that's representative of the WG as a whole? Or is it going to be on behalf of certain members?

stonematt: Good question, let's discuss later.

PRs for Data Model

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

<scribe> scribenick: jonathan_holt

<manu> https://github.com/w3c/vc-data-model/pull/708

manu: PRs 708 is to prevent copying of example and using friendly colors, css. Ted has confirmed that it works. we are good to merge
... no objections were noted.

<manu> https://github.com/w3c/vc-data-model/pull/710

manu: PR 710 brent submitted with comments from Ted

brent: we had an issue come up with a response. I don't care if it is merge. goal is to smooth some issues.

manu: +1 , but the type is jwk and it isn't shown and would be a non-normative change. we could use something like "name". if we want to add jwk it might be an issue

<dlongley> another option is `urn:example:jwk`

brent: I will steal what was suggested.

manu: will need to update the example
... i'm going to hold off for now.

dave: example above "urn"

manu: did security group comment on type?

brent: I am will to go however.

manu: let's go with example.jwk and try to look back at what comment meant. may take me a bit
... a bit of a messy proposal
... brent, could you take another look at it?

brent: ok

<manu> https://github.com/w3c/vc-data-model/pull/711

manu: re 711 there has been a lot of chatter between folks.

<manu> https://github.com/w3c/vc-data-model/pull/711/files

David: the first one is that it doesn't exist. they all were minor. "all must represent the subject of the consumer". so I removed the subject
... Ted suggested a longer fix. the second one referred to the claim and was abiguious between jwt etc. I added VC and created massive discussion despite my thought is was minor
... the last (third) one was a typo. should have simple should have been VC property.

ted: I would like to get some more thoughts and don't think I got to where i wanted to.
... the big one is the mess of inconsistent usage. This PR regarding to JOSE claims don't exist. there are JOSE headers and JWT claims. but no JOSE claims. I am no expert in JWT and need help.

manu: The first one doesn't create a normative change and will affect implementers.

ted: advise it is not "must"

dave: if we remove the "must' then it is a normative change

manu: Ok. Ok. ahhhh

<manu> https://github.com/w3c/vc-data-model/pull/711/files#diff-eacf331f0ffc35d4b482f1d15a887d3bR3569

manu: line 3569, dave your are talking about line 3565

ted: there is only one "must" that changes the meaning
... the unclear is still unclear and the old must hasn't reached clearity.

manu: this is in the JWT section?

<Zakim> manu, you wanted to ask if the last change is normative? and to ask if the second change is normative?

<manu> https://github.com/w3c/vc-data-model/pull/711/files#diff-eacf331f0ffc35d4b482f1d15a887d3bR3632

manu: line 3662 looks like a normative change. thoughts?

ted: it definitely reads like a change. test suite might pass.

manu: the watermark is if someone read this would they change their implementation.

Ted: if you make it about the subject and not the .... non-the-less this is what people are instructed to do. it is a nested property and could happen

<manu> +1 to what oliver is saying

oliver: a few things to add color. 1.) implementations does it create any changes. does the test suite affected. 2.) JOSE claims there is the IANA registry and if we use the IANA registry the we should use JWT claims. There is no difference as both describe the credential subject.

manu: i agree, but need to read it thru

Justin_R: JOSE is just the crypto. JWT is the payload spec and the only part that can have claims. JWT wan't done in the JOSE working group. JWT payload claims is OK, I recommend JWT claims. Reading the text, I can see how this could be a normative change, however, it is more specific about what is being required. while it is possible that someone could implement it poorly. My take is that it is non-normative, but I can see how some might see it as normative

.

<stonematt> ak Justin_R

<Zakim> Justin_R, you wanted to talk JOSE

manu: i think we will continue processing, at present we can't merge as we don't have finality.

<TallTed> separating into 3 PRs may be a good idea

<stonematt> +1 to >1 PR

Ted: I have a better understanding and will try but the old text might just be bad.

manu: This may trigger JWT section to be pulled and put into it's own
... so those are the PRs.

scribe?

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

Issues

<manu> https://github.com/w3c/vc-data-model/issues/704

manu: regarding 704 people can copy in all examples, ted are you happy?

ted: i am happy with what i have seen

manu: manu reading what he is typing

ted: this bit of magic should be shared with w3c

<ken> I am happy with the ... handling

manu: should we as markus and make it part of respec to make it happen automatic

<manu> https://github.com/w3c/vc-data-model/issues/709

<burn> they can add an option in code to leave out comments or not

<manu> https://github.com/w3c/vc-data-model/issues/709#issuecomment-518854709

manu: re 709 we should look at Joe's response. submitter says he can't do this thing. making JWK as the issuers. Issuers don't want to tie their issuer to a key. If someone wants to do it, the spec does support it as pointed out by Joe
... we may want some more responses, the suggestion is to say .. "hey, we have a PR that addresses it. respond with a 7 day close. if we don't get the PR in and the comment doesn't follow it will be after the deadline."
... heads up. the second CR period end and we wanted to immediate call for a vote and if we fail to get submitters issue in then it pushes when we want to do a proposed rec.
... putting in a proposal, reading while he is typing.

<manu> PROPOSAL: Issue #709 is addressed by PR #710, which adds a non-normative example to the specification demonstrating how an issuer value can be a dictionary (a set of key-value pairs).

<TallTed> +1

<manu> +1

<stonematt> +1

<deiu> +1

<dlongley> +1

<burn> +1

<oliver> +1

<ken> +1

RESOLUTION: Issue #709 is addressed by PR #710, which adds a non-normative example to the specification demonstrating how an issuer value can be a dictionary (a set of key-value pairs).

manu: i will put this in the issue with a 7 day close
... those are all the remaining issues

stonematt: now onto the test suite

scribe?

<dmitriz> https://github.com/w3c/vc-test-suite/issues

<manu> scribenick: manu

Test Suite

https://github.com/w3c/vc-test-suite/issues

<dmitriz> https://w3c.github.io/vc-test-suite/implementations/

<dmitriz> https://w3c.github.io/vc-test-suite/implementations/

dmitriz: I've added an implementation count for each feature
... I've linked to the implementation source code repos that we know about.
... There are some issues with JWT implementations, we have only one implementation for two features.

<TallTed> dmitriz - can the section links be made to actually link to the sections?

oliver: From uPort perspective nothing changed, our new test report should only have green tests.

dmitriz: hmm, so just a couple of uPort test results where it shows up red. You can look at errors in test report JSON. It'll give the error message.

oliver: I did move one test case to presentation section... audience doesn't make sense in credential itself. Did that cause a problem?

dmitriz: I don't think so, new test shows up as untested... green for uPort and untested for the rest, because it's new.

<Zakim> manu, you wanted to note that we need to get implementation reports settled.

<TallTed> stonematt - the HTML has `<h4 id="evidence-optional">Evidence (optional)<a class="self-link" aria-label="§" href="#conformance-testing-results"></a></h4>` so the href doesn't have the correct target id

<TallTed> stonematt, dmitriz - fixing this should hopefully also fix the TOC which doesn't list the sub-sections as I would hope it would

<dmitriz> @TallTed - ah, ok, so, I'll just fix the h4 id?

manu: We need to make sure we have full implementation reports in in the next 7 days.

<TallTed> dmitriz - no, the h4 id is correct. it's the associated a that targets the wrong id

oliver: No problem, we are going to fix our test report.

dmitriz: Big thanks to Kaz and W3C sysreq for fixing content-type for JSON-LD contexts... those work now.
... I need to fix CSS in implementation report.

<TallTed> above HTML should be `<h4 id="evidence-optional">Evidence (optional)<a class="self-link" aria-label="§" href="#evidence-optional"></a></h4>`

<dmitriz> TallTed: thanks

stonematt: Only a few days left in CR period, is expectation that these issues are closed this week, or next week?

dmitriz: They can be closed right now.

<TallTed> dmitriz - that HTML error is seen throughout, i.e., on every sub-section header

manu: We need to fix table of contents.

dmitriz: Yes, will do.
... That's it for test suite.

Implementation Guide

<deiu> https://github.com/w3c/vc-imp-guide/pulls

<deiu> https://github.com/w3c/vc-imp-guide/pull/26

deiu: Just a small section for the intro... we haven't officially had someone approve these PRs.
... This is just 3 paragraphs. Ted has taken a stab at it, suggested a few changes, Brent has made them.

Justin_R: On quick read, the opening sentence is condescending.

<stonematt> +1 to that sentiment

Justin_R: This guide provides some resources and examples for implementing beyond what's in the core specification...
... I suggest wordsmithing that...

<deiu> https://github.com/w3c/vc-imp-guide/pull/27

deiu: Thoughts, Ted?

TallTed: I'm fine w/ it based on my changes.

<deiu> https://github.com/w3c/vc-imp-guide/pull/28

deiu: This is mostly editorial...
... Has been reviewed by Ted...
... Brent hasn't addressed Ted's last comment from yesterday...

Brent: That effort is going to have to be a separate PR.
... doesn't need to be a part of this PR.

stonematt: Weren't we going to remove the table?

<TallTed> +1 Brent's comments on the potential table consolidation

Brent: The table never left, we're consolidating... maybe...
... I'm going to try to combine them
... I'm going to do that in a separate PR

manu: +1 for doing that in a separate PR.

TallTed: With that, I'm good with this PR with where it is.
... I think it's ok to have two sections and two tables with inverted language... all green, all green, presenting opposite side.

<stonematt> q/

stonematt: This is something that's important, but don't want to focus on that now as there are other higher priority things to focus on.

<brent_> gotcha

stonematt: We can merge this one and at least have two new updated tables.

deiu: Need Ted to approve this and then I can merge.

<deiu> https://github.com/w3c/vc-imp-guide/pull/32

deiu: Anyone don't want to merge this?

brent_: Wasn't it in draft form?

deiu: It had two approvals.

brent_: I'm fine w/ merging, but I may add more to it. I can do that in a different PR.

deiu: If you want to keep this open, change it to Work In Progress (WIP)

deiu and brent decide to keep it open, no merge, no keep it open, no use github draft issues, no keep it open... and merged.

<deiu> https://github.com/w3c/vc-imp-guide/pull/33

deiu: This is pretty straight forward...
... any objections to merge?

manu: +1 to merge

<deiu> https://github.com/w3c/vc-imp-guide/pull/34

deiu: This one moves the hashlink stuff to the content integrity section.

<deiu> https://github.com/w3c/vc-imp-guide/pull/38

<brent_> conflicts are resolved on 34

deiu: This one is easy, fixing typos

manu: +1 to merge

deiu: merging 34 and then merging 38

<deiu> https://github.com/w3c/vc-imp-guide/pull/30

deiu: Make disputes their own section

manu: +1 to merge

deiu: Any objections to merge?

<deiu> https://github.com/w3c/vc-imp-guide/pull/17

deiu: we're awaiting content on the schema examples

jonathan_holt: Made some progress, still stuck on proof section and using some examples from test suite. Just to clarify, a proof section is just an object, no other subschemas?

deiu: We were handwaving in data model

jonathan_holt: Making progress...

manu: +1 to jonathan_holt for working on the schema! Thank you! :)

<deiu> https://github.com/w3c/vc-imp-guide/issues

deiu: Some of these are associated with the PRs we just merged.
... None of these issues are related to the PRs we just closed...
... There are a bunch that are really old
... Most of those are supposed to be getting a PR from Dave... guess we're still waiting for them.

dlongley: Can have a PR for these in a minute.

<gannan> Can someone make me the assignee for https://github.com/w3c/vc-imp-guide/issues/4?

brent_: I made changes that you were looking for in PR 26, intro section.

<deiu> https://github.com/w3c/vc-imp-guide/issues/22https://github.com/w3c/vc-imp-guide/pull/26

deiu: any objections for merging 26?
... hearing no objections, merging... only two PRs left...

<deiu> https://github.com/w3c/vc-imp-guide/issues/22

deiu: Moving back to issue 22

TallTed: The example uses schema.org and hardcodes to it... either it's immutable or its not, if it's changeable, should not be basis of hardcoding anything.

stonematt: This doesn't seem like an issue that's unique to us as a group, is there some other technique or practice?
... Is there a best practice?

TallTed: given what we're doing, we're focusing on VCs, knowing what's going on, we can't do the handwave/

<Zakim> manu, you wanted to note solution, maybe

<dlongley> scribenick: dlongley

manu: We can make statements about hashlink contexts, vocabs and that you need to pay attention to this stuff and not change semantics over time.

<manu> TallTed: This is talking about how to build a vc on a new vocab

TallTed: The thing that's being presented is ... it's talking about how do you create a new thing, how you build your own vocab, how do you make sure the verifier understands what you've issued.

<scribe> scribenick: manu

jonathan_holt: This is a grounding problem w/ semantics, if it's turtles all the way down, if we have TimBL at the bottom, we have an authority.
... The important thing here is grounding and having one entity/organization stating what the semantics mean.

TallTed: This is not about interop, this is about issuing a VC based on a vocab that someone else has put in play... so neither I or the verifier can contact the vocabulary maintainer and ask them about the semantics.

<dlongley> this is about risk profile, not about whether or not something is "totally broken"

dmitriz: Clarification from Ted, we have the ability to refer to a particular version of schema, lock credential to that version... in some cases, Sovrin-based ledgers, that schema is cryptographically encapsulated.
... So, we have mechanisms to do that... is your question "how do we get people to understand schemas"?

TallTed: Right now, the mechanism is schema.org -- it doesn't point to schema.org/v1 or schema.org?hl=z8a3as7d4n897
... I'm asking for the example to be verifiable and solid for the future, this is what we're going to expect other people to do for themselves.

stonematt: This went a different direction than I thought I was thinking... if we have a technique speaks to this challenge, we should include that in our examples. So the community gets the benefit of our thinking, strong +1 to that.
... There is uncertainty because this is open world, but if there is a way to resolve that uncertainty, let's note that.

TallTed: Open world means that anything that I say, I have said, and anything that I don't say is indeterminate.

<stonematt> +1 to improving the examples

TallTed: If I have it in my knowledge base then I know it; if I don't, I know nothing.

stonematt: The ask that you're making is amend/enhance examples with these techniques?

TallTed: We are doing Verifiable Credentials, we need to let people build something where they know what I'm talking about... that needs to be in the example.
... The real test is to put this in front of someone that knows nothing about what we've done here and does it.

<Zakim> deiu, you wanted to say we should add best practices of limkimg (ffs) to versiomed schema.org?

deiu: There is a way to link to specific versions of schema.org releases... we can say "these are the best practices of using mutable vocabularies"
... Then we can say "use that particular URL in the context".

TallTed: Right now we're talking about schema.org that let's you specify a URL... schema.org is an example in this context, we have to provide solutions for not so well behaved producers.

deiu: This has been a philosophical debate dragging on for years and years...

<Zakim> manu, you wanted to note one example.

scribenick: dlongley

manu: There are multiple ways to say this; I hesitate to say that anyone who is unfamiliar with semantics can do it right the first time. We could say you need to do two things: To achieve something close to the ideal solution you need to be able to lock down the semantics and the context. You lock down the semantics by releasing versions of the semantics document and you lock that down with a specific version, e.g., for schema.org these are 2018 semantics.
... The problem with doing that is that you have to express those properties in the context but when compacted they look the same as other VCs but the semantics may differ. The communities that are putting these VCs together that you can't change the semantics.

TallTed: We can't do that -- we have to say you can't use someone else's vocabulary or we provide the mechanisms by which these problems are resolved.

<Zakim> JoeAndrieu, you wanted to mention the square peg round hole problem (BTCR hackathon)

<bigbluehat> i.e. every credentialing community will have it's own vocabulary restrictions--and therefore context dereferencing/caching/publishing approaches

scribenick: manu

JoeAndrieu: There is a problem here not just with the schema, but with data modelling.
... There was a way to come up with VC for "knows" relationship... there was a strong drive among engineers to use schema.org, but we were shoehorning what we wanted into schema.org... everyone that builds a VC out of this is going to have their own data modelling challenges.

bigbluehat: I do think this is credential community space, they need to have their own policies around permanence. The web lacks object permanence, every credentialing community will have to do a good job locking this stuff down in their own way. I don't think we can solve this in an example.
... This is the thing we've been up against w/ the Web since it's inception, we can throw new technologies at it, but may be difficult to get this across in the implementers guide.

stonematt: This is a big topic, perhaps we can provide some guidance in implementation guide, let's move on to next topic.

deiu: Let's keep the conversation going using github comments.
... Let's see if we can make constructive comments in the issues.

<JoeAndrieu> https://github.com/w3c/vc-use-cases/

Use Case Document

https://github.com/w3c/vc-use-cases/

<JoeAndrieu> https://github.com/w3c/vc-use-cases/issues

JoeAndrieu: Let's talk about issues and 3 PRs.
... We have 19 issues right now, Matt and I have been working to get those whittled down. If any of these issues are yours and you care about them, get a PR in. Some of potential use cases, some need a PR, some are editorial, some are out of date, if any of these are yours, we need a PR.
... We need closure on rest of document... we need to publish same as Implementation Guide.

stonematt: We need to get this wrapped up in next 1-2 calls... we'll call for a vote to publish.
... We're asking "is this good enough" rather than "what do you want to add"?
... So, we may run out of time.

<JoeAndrieu> https://github.com/w3c/vc-use-cases/pulls

JoeAndrieu: Let's look at current PRs.

https://github.com/w3c/vc-use-cases/pull/100

JoeAndrieu: I'd like folks to take a look at it to merge it in.

stonematt: I'll look at it, expecting content didn't change, I'm sure it's in line with what we wanted.

JoeAndrieu: Not a lot of edits/commentary... may have lost TallTed's edits.
... Next one, thanks to Reiks and Ken for getting their PRs in... device use cases from Ken...

https://github.com/w3c/vc-use-cases/pull/105

JoeAndrieu: Looks good, have some changes around use of "identity" here... don't know how to suggest changes.

Justin_R: Hit + when you want to change beside line, then put suggested change line in triple backticks, you can put that in comments, not clear if there is a way to push it, can put it in suggested changes...

<TallTed> JoeAndrieu - My change was just a typo fix on the request for comments on the doc ... which appears to have been removed entirely, so no worries.

JoeAndrieu: I will get that in, small changes, should be good to go.
... Last one, might kick this one around for a few minutes, from Reiks...

https://github.com/w3c/vc-use-cases/pull/103

JoeAndrieu: In this document, we list some user tasks, what can you do with VCs?
... You can issue, verify, etc.

<stonematt> https://w3c.github.io/vc-use-cases/#user-tasks

JoeAndrieu: User tasks, Reiks raised an issue, raised a PR, ... so, you've verified a credential... how do you know if you can rely on this statement from issuer X?
... For tasks that user is going to do with a claim, he put in some language about what that might mean, wanted to get a sense from group about adding that.
... I'm not sure trust is the best vocabulary term.

<TallTed> this is all policy.

dmitriz: So this is key... probably hardest problem that we have, my slight issue w/ that PR, line 594, it must be able to do this in an automated fashion.

JoeAndrieu: Yeah, that's an issue.

dmitriz: That may not be possible? Any sort of trust mechanism, there is usually a human involved.

<TallTed> "I only accept driver's license as granting a license to drive in municipality, if issued by DMV of governing body."

<burn> Yes, this is the human piece.

stonematt: Really gets to idea of trust... one of the things that came out of this discussion in last two weeks, is clarified definition of verify... included checking status method and so on... we had stuff in verify loop that are related to an earlier version of this idea of trust.
... The trusting language has to do with policy, judgement, and reasoning that an organization is going to overlay on top of verification process... not entirely technical and automated.
... trust and rely upon might be better served with language like that.

<Zakim> manu, you wanted to say validation?

scribenick: dlongley

manu: I thought we were classifying this whole trust thing as validation not verification. Seeing if it was valid included checking the issuer.

JoeAndrieu: +1 that's the better term

<burn> +1 manu

<JoeAndrieu> +1 to "validation"

<TallTed> "If issuer is recognized as appropriate governing body for credential being verified, accept statements as in that credential. If issuer is not recognized, flag for human review."

<stonematt> +1 to manu and TallTed -- scope and context matters for trust.

manu: I want to push back a bit on automation, sometimes you can automate and only pull the human in when the checks won't work for you. Ted put a great example up there. You can say you trust DMVs to issue driver's licenses -- and you can imagine a world, e.g., in the US where you list all 50 state DMVs and you accept any of those.

<stonematt> validation after verification is a mechanism to achieve trust.

manu: So it's policy and you can automate some of it but you can also change that policy in a manual way. Some states, for example, might not take driver's licenses from other states or tribal IDs from native nations or whatever. Validation -- and there's a way to make it automatic but a human guides/updates policy.

<Zakim> burn, you wanted to talk about automation

scribenick: manu

burn: I love the DMV example because it's broken... the state of Georgia, the DMV issues license plate, Driver Services issues driver's licenses.
... Example I give is, which educational institutions have public IDs, some group is in charge of that... but that site could be hacked, so it's my decision (this is Manu's policy statement), maybe there are 3 servics that do this, if I get a mismatch somewhere, a human being looks at it.
... I don't like the term automatic, it makes it seem like there is no human piece... the human piece decides which source of information to trust. We are not saying we're trusting one Root CA for everything, every user of credentials gets to make that choice.

<dlongley> humans decide policy ... and then employ technological agents to enforce it

ken: Two different points, there can be some automation -- accrediting board for universities may issue credential that says "these institutions are approved to issue"
... You still have the "turtles all the way down" problem... you do need to make clear distinction between verification and validation.
... Verification can be partially automated, not mandatory that it is in requirements.

<Zakim> JoeAndrieu, you wanted to talk about DMVs

JoeAndrieu: I'll wrap with a short note, thanks for the feedback... turns out in california, any DMV in the world makes it valid to drive in California.

stonematt: We need to make some decisions to publish, need your help, please continue to jump in and contribute.

<jonathan_holt> i would just add "cryptographically valid" which includes fetching and validating signature and non-revoked compared to "syntactically valid" which means the VC is properly formatted.

[adjourned]