- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Thu, 15 Aug 2019 17:03:58 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2019/08/13-vcwg-minutes.html
also as text below.
Thanks a lot for taking these minutes, Manu, Dave and Jonathan!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Verifiable Claims Working Group
13 Aug 2019
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Aug/0012.html
Attendees
Present
Adrian_Gropper, Andrei_Sambra, Benjamin_Young,
Brent_Zundel, Dan_Burnett, Dave_Longley, David_Chadwick,
Dmitri_Zagidulin, Justin_Richer, Ken_Ebert, Manu_Sporny,
Matt_Stone, Ned_Smith, Sercan_Kum, Ted_Thibodeau,
Jonathan_Holt, Oliver_Terbu, Joe_Andrieu, Kaz_Ashimura,
Ganesh_Annan
Regrets
Amy_Guy
Chair
Matt_Stone
Scribe
manu, dlongley, jonathan_holt
Contents
* [3]Topics
1. [4]PRs for Data Model
2. [5]Issues
3. [6]Test Suite
4. [7]Implementation Guide
5. [8]Use Case Document
* [9]Summary of Action Items
* [10]Summary of Resolutions
__________________________________________________________
<scribe> scribe: manu
Chairs look for a scribe...
<stonematt>
[11]https://lists.w3.org/Archives/Public/public-vc-wg/2019Aug/0
012.html
[11] 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> [12]https://github.com/w3c/vc-data-model/pulls
[12] https://github.com/w3c/vc-data-model/pulls
<scribe> scribenick: jonathan_holt
<manu> [13]https://github.com/w3c/vc-data-model/pull/708
[13] 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> [14]https://github.com/w3c/vc-data-model/pull/710
[14] 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> [15]https://github.com/w3c/vc-data-model/pull/711
[15] https://github.com/w3c/vc-data-model/pull/711
manu: re 711 there has been a lot of chatter between folks.
<manu> [16]https://github.com/w3c/vc-data-model/pull/711/files
[16] 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>
[17]https://github.com/w3c/vc-data-model/pull/711/files#diff-ea
cf331f0ffc35d4b482f1d15a887d3bR3569
[17] 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>
[18]https://github.com/w3c/vc-data-model/pull/711/files#diff-ea
cf331f0ffc35d4b482f1d15a887d3bR3632
[18] 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:
[19]https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is%3Ai
ssue+is%3Aopen+-label%3Adefer+
[19] https://github.com/w3c/vc-data-model/issues?utf8=
Issues
<manu> [20]https://github.com/w3c/vc-data-model/issues/704
[20] 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> [21]https://github.com/w3c/vc-data-model/issues/709
[21] https://github.com/w3c/vc-data-model/issues/709
<burn> they can add an option in code to leave out comments or
not
<manu>
[22]https://github.com/w3c/vc-data-model/issues/709#issuecommen
t-518854709
[22] 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> [23]https://github.com/w3c/vc-test-suite/issues
[23] https://github.com/w3c/vc-test-suite/issues
<manu> scribenick: manu
Test Suite
[24]https://github.com/w3c/vc-test-suite/issues
[24] https://github.com/w3c/vc-test-suite/issues
<dmitriz>
[25]https://w3c.github.io/vc-test-suite/implementations/
[25] https://w3c.github.io/vc-test-suite/implementations/
<dmitriz>
[26]https://w3c.github.io/vc-test-suite/implementations/
[26] 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> [27]https://github.com/w3c/vc-imp-guide/pulls
[27] https://github.com/w3c/vc-imp-guide/pulls
<deiu> [28]https://github.com/w3c/vc-imp-guide/pull/26
[28] 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> [29]https://github.com/w3c/vc-imp-guide/pull/27
[29] https://github.com/w3c/vc-imp-guide/pull/27
deiu: Thoughts, Ted?
TallTed: I'm fine w/ it based on my changes.
<deiu> [30]https://github.com/w3c/vc-imp-guide/pull/28
[30] 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> [31]https://github.com/w3c/vc-imp-guide/pull/32
[31] 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> [32]https://github.com/w3c/vc-imp-guide/pull/33
[32] https://github.com/w3c/vc-imp-guide/pull/33
deiu: This is pretty straight forward...
... any objections to merge?
manu: +1 to merge
<deiu> [33]https://github.com/w3c/vc-imp-guide/pull/34
[33] https://github.com/w3c/vc-imp-guide/pull/34
deiu: This one moves the hashlink stuff to the content
integrity section.
<deiu> [34]https://github.com/w3c/vc-imp-guide/pull/38
[34] 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> [35]https://github.com/w3c/vc-imp-guide/pull/30
[35] 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> [36]https://github.com/w3c/vc-imp-guide/pull/17
[36] 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> [37]https://github.com/w3c/vc-imp-guide/issues
[37] 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
[38]https://github.com/w3c/vc-imp-guide/issues/4?
[38] https://github.com/w3c/vc-imp-guide/issues/4?
brent_: I made changes that you were looking for in PR 26,
intro section.
<deiu>
[39]https://github.com/w3c/vc-imp-guide/issues/22https://github
.com/w3c/vc-imp-guide/pull/26
[39] 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> [40]https://github.com/w3c/vc-imp-guide/issues/22
[40] 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> [41]https://github.com/w3c/vc-use-cases/
[41] https://github.com/w3c/vc-use-cases/
Use Case Document
[42]https://github.com/w3c/vc-use-cases/
[42] https://github.com/w3c/vc-use-cases/
<JoeAndrieu> [43]https://github.com/w3c/vc-use-cases/issues
[43] 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> [44]https://github.com/w3c/vc-use-cases/pulls
[44] https://github.com/w3c/vc-use-cases/pulls
JoeAndrieu: Let's look at current PRs.
[45]https://github.com/w3c/vc-use-cases/pull/100
[45] 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...
[46]https://github.com/w3c/vc-use-cases/pull/105
[46] 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...
[47]https://github.com/w3c/vc-use-cases/pull/103
[47] 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> [48]https://w3c.github.io/vc-use-cases/#user-tasks
[48] 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]
Summary of Action Items
Summary of Resolutions
1. [49]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).
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [50]scribe.perl version 1.154 ([51]CVS log)
$Date: 2019/08/15 08:01:40 $
[50] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[51] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 15 August 2019 08:05:03 UTC