- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Tue, 16 Apr 2019 22:41:26 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2019/04/09-vcwg-minutes.html
also as text below.
Thanks a lot for taking the minutes, Amy and Yancy!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Verifiable Claims Working Group Meeting
09 Apr 2019
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Apr/0005.html
Attendees
Present
Manu_Sporny, Amy_Guy, Andrei_Sambra, Sercan_Kum,
Justin_Richer, Dave_Longley, Brent_Zundel, Ken_Ebert,
Adrian_Gropper, David_Chadwick, Oliver_Terbu,
Matt_Stone, Allen_Brown, Benjamin_Young, Jonathan_Holt,
Ted_Thibodeau, Yancy_Ribbens
Regrets
Kaz, tzviya, chaals
Chair
Matt_Stone
Scribe
rhiaro, yancy
Contents
* [3]Topics
1. [4]PR Review
2. [5]Open issues
* [6]Summary of Action Items
* [7]Summary of Resolutions
__________________________________________________________
<manu> scribenick: rhiaro
<stonematt>
[8]https://lists.w3.org/Archives/Public/public-vc-wg/2019Apr/00
05.html
[8] https://lists.w3.org/Archives/Public/public-vc-wg/2019Apr/0005.html
stonematt: the CG call is generally after this WG call, but
they cancelled this week. Many of us go to both, and since we
have more VCWG work to do than we can do in an hour we're
offering to extend this call another hour for anyone who can
attend. We'll get as much processeed as possible
... Anything you need to do now to make your next hour
available, do it now
PR Review
<stonematt> [9]https://github.com/w3c/vc-data-model/pulls
[9] https://github.com/w3c/vc-data-model/pulls
manu: I'm going to go down the entire list of PRs starting at
the oldest
<manu> [10]https://github.com/w3c/vc-data-model/pull/501
[10] https://github.com/w3c/vc-data-model/pull/501
manu: First is 501. This had a number of questions around
refreshService
... david chadwick proposed some changes, ken responded with a
list of questions and in an attempt to not have a tremendous
amount of back and forth in the issue I suggested a call to
discuss this, there are some big disconnects still on this
feature
... once bringing david and ken up to speed we can try to
figure out what text will resolve ken's concerns
ken: I submitted last night a new PR to address this issue,
that's number 458
... I think it's a serious issue, the deeper I understand
refreshService the more critical I think it is we address it. I
thinkt he way it was written undermines the holder's ability to
control their data and their interactions, so I put together a
pr that addresses that
dlongley: I think as written we would object to ken's pr
... so we're going to have to take a closer look at that
... is it 540?
ken: yes
<stonematt> [11]https://github.com/w3c/vc-data-model/pull/540
[11] https://github.com/w3c/vc-data-model/pull/540
dlongley: the changes that are put into here might make it so
the refreshService is only usable under certain conditions that
would only apply to certian use cases rather than others. We're
trying to make sure you could use a refresh service to cover
all the possible use cases. We will have use cases where there
are issuers that want to allow verifiers to pull information
after holders haves hare those credetianls. HOlders should be
aware those vcs
work that way but that wouldn't prohibit the vcs form working
scribe: [scribe got lost]
ken: that is the exact use case that I think undermines the
ability for the holder to control their data
... if it stays in that way, Sovrin will withdraw support. I
cannot convince my boss to vote for it
dlongley: sovrin doesnt' have to support a very specific
refresh service that allows it to happen
... this allows to calll a space where refresh services can
reside, where you put that information. Sovrin is under no
burden to support a refresh sservice that covers use cases they
don't want to cover. All they have to do is support the space,
so other people can create refreshservices that function the
way they need
DavidC: either we're going to discuss it now or we're not..
manu's original proposal was we discuss it offline which we
haven't yet. But if we are going to discuss it now I want to
raise a point
<Zakim> manu, you wanted to prevent discussion and move on.
stonematt: I think we should table it and discuss it later or
in another call so we can continue to process
<ken> +1
<dlongley> +1 to no discussion today
manu: If it gets into discussion we need to stop it, we have a
lot to get to, 21 issues, if it's not a resolution we move on
... Those two PRs are stuck until this gets discussed. ken,
david, we will have to find another time to have that
discussion asap
<SercanK> +1 interested
<ken> agreed
manu: that's a big change we're talking about
<DavidC> +1
manu: Next PR is 508
<manu> [12]https://github.com/w3c/vc-data-model/pull/508
[12] https://github.com/w3c/vc-data-model/pull/508
manu: brent I just need you to resolve the conflicts
... never mind I can do that
... That's good to go
<stonematt> [13]https://github.com/w3c/vc-data-model/pull/514
[13] https://github.com/w3c/vc-data-model/pull/514
brent: resolved them yesterday
manu: 508 is ready to go in
... 514, there are a number of updates that grant did to the
spec
<oliver> I would like to be part of the discussion if you have
a dedicated call
manu: *reads all the editorial pr numbers*
... grant did a broad search and replace and changed every
instance of credential to verifiable credential. They are two
different concepts. A credential doesn't have any kind of proof
mechanism associated with it, a VC does. The changes wipe out
that distinction
... There are 63 places where that change was made that needs
to be reverted. I have marked all of them, grant says he's
gonna process them. All of those editorial changes to the spec
are stuck until that happens
... Next is pr 531
<manu> [14]https://github.com/w3c/vc-data-model/pull/531
[14] https://github.com/w3c/vc-data-model/pull/531
manu: This PR attempts to clarify that multiple proof mechanims
are allowed, brent and chaals have approved it, I wrote it.
We're holding on justin because you wanted to review this pr
... once you do a reivew and suggest concrete changes or just
approval we can pull that pr in
... 531 is blocked on justin
Justin_R: i'll take a look
<manu> [15]https://github.com/w3c/vc-data-model/pull/532
[15] https://github.com/w3c/vc-data-model/pull/532
manu: next one is also justin, 532. Jonnycrunch, Justin and I
had a discussion last week where justin noted issues and
concerns with the syntaxes section
... we're a little too loose with the language around how
certain serialisations should or must happen in the spec. I've
added 4 paragraphs of text to syntax to try to make that
clarification
... justin I need you to review it to make sure I'm addressing
your concerns appropriaately. dlongley has already suggested
changes which I haven' tupdated the pr yet
... if anybody else has concerns about the language in the
syntaxes section please review this
... the second justin gets his reivews in we're going to pull
that in unless there are objections
Justin_R: you had asked me last week to actually address that
text so I didn't see this change come across and we'll get to
it but 539 was my take on this
manu: I hadn't seen that yet
Justin_R: it can't be merged because of the ipr bot
manu: we'll ping kaz and the chairs on that
... you are a part of the group we just need someone to..
Justin_R: I'm working on fixing that right now, but if we're
going to talk about the text in 532 we should talk about the
text in 539
manu: we sholud take this offline and put aside time this week
to do that
<manu> [16]https://github.com/w3c/vc-data-model/pull/533
[16] https://github.com/w3c/vc-data-model/pull/533
manu: Next is 533
... an update that brent made to address issue 474
... I think it was approved, DavidC is pushing back on it and
dlongley has responded. We're gonna have to let this one ride
... please try and resolve stuff in the issue
... DavidC I think this is blocked on you until you say whether
you agree with the text
<manu> [17]https://github.com/w3c/vc-data-model/pull/534
[17] https://github.com/w3c/vc-data-model/pull/534
manu: 534 is next
... this is by brent. DavidC did brent's changes address your
concerns?
<manu>
[18]https://github.com/w3c/vc-data-model/pull/534#discussion_r2
73367840
[18] https://github.com/w3c/vc-data-model/pull/534#discussion_r273367840
DavidC: on the context one?
... I haven't seen a response to.. oh I see okay
manu: changing a MUST to a MAY, brent is asserting it's a
mistake the group made, I don't think it was
... if it was not a mistake it's a normative change
... as a heads up to anyone else doing PRs any time you touch a
SHOULD or a MUST or a RECOMMENDS it's a normative change and
you need to get the entire group to agree we didn't actually
mean the MUST
... David, brent, myself, dlongley, anyone else you need to get
together to decide the exact spec text. If there's a way to
make this change and make it non-normative that would be best.
if it's normative change we'll have to go through another CR,
which we're trying to avoid
... Need to take this offline
<brent> +1
<manu> [19]https://github.com/w3c/vc-data-model/pull/535
[19] https://github.com/w3c/vc-data-model/pull/535
manu: Next is 535
... brent has written this to address 483 about context and 491
... brent what's the status here? I can merge
brent: I updated it according to your comments
... yesterday. But other than you nobody has reviewed it
DavidC: when you say doesn't require the value to be
processed.. what does that mean?
... Does that mean even read and understood? or does it mean
referenced and fetched and everything
manu: it does not mean dereferencend and fetched. It means the
array is in the order you expect - this is for json processors
processing @context - you don't need to dereference you don't
need to do json-ld processing
... but you need to do a byte to bye tstring compare to make
sure the items in the array are in the same order you expect
DavidC: it says there is no requirement that the value is
processed
manu: it says specificially to be processed using JSON-LD
... brent has updated the text
DavidC: right okay
manu: david and anyone else who wants to do a review please do.
Right now it has an appropriate number of reviews to pull it in
(at least 2)
... 535 is ready, please reivew if you have something to say
<manu> [20]https://github.com/w3c/vc-data-model/pull/538
[20] https://github.com/w3c/vc-data-model/pull/538
manu: Next 538
... brent, update on this one?
brent: this is in response ot issue 488 which is just attempts
at adding non-normative clarifying text to the presentation
section
... I've added a couple of paragraphs worth of text
... or reordered things
... I don't think I"ve changed the meaning of anything, just
tried to explain more
ken: does have new normative language in it
brent: where?
ken: line 1621 has a must, line 1690 has a may
manu: it existed in the old language
... 1644 and 1643 on the other side
ken: I just wanted to call it out to make sure
brent: that's a paragraph I moved so all the normative
statements are in the same place
manu: this just needs reviews
<manu> [21]https://github.com/w3c/vc-data-model/pull/539
[21] https://github.com/w3c/vc-data-model/pull/539
manu: The last pr that's pending is justin, 539
... we need to review, we'll do that
<manu> [22]https://github.com/w3c/vc-data-model/pull/540
[22] https://github.com/w3c/vc-data-model/pull/540
manu: 540 is one that ken just put in
... that we also need to review
... DavidC is disagreeing with the proposed update. We will
continue going through that PR in the thread
... Any comments/concerns about the way we're processing these
or next steps?
... Next step is let's try to get a big call with all of us
there and try to address the PRs that we feel are easiest first
and then more difficult second
... if certain people that need to be there who are contesting
the PR or pushing the PR aren't there we are just going to have
to have a separate call. Let's try and put this earlier in the
week, possibly wed/thu/fri of this week
... and push forward resolutions for those
Open issues
manu: Justin, you were on that call and yo ucould let us know
whether or not jonnycrunch would disagree with this PR.. I
think he would agree with it
Justin_R: I'm not going to pretend to speak for him and I
believe you should not either
manu: we can't resolve any of the issues jonnycrunch had a
concern with if he's not here. We'll have to make sure he's on
the call when we address stuff
... It's really only the @context issue, and that's a
foundation issue for some of the other sub-issues
<manu> [23]https://github.com/w3c/vc-data-model/issues/491
[23] https://github.com/w3c/vc-data-model/issues/491
manu: First is 491
... raised by tony nadalin, says no need to process the context
unless dealing with jsonld and processing should be made
optional. The assertion is that it was always optional for non
jsonld processors modululo that one thing where you have to
make sure the order is appropriate. The suggestion is to add
non normative text making that more clear. brent already has a
PR in for that. Part of that's there. THere's another set of
text we shoul add in
5.3.1 outlininig you shouldn't have to do full blown
compaction/expansion kind of stuff to be compatible
scribe: the suggestion is to add non-normative text to the spec
that clarifies this
Justin_R: I think the core of this is one that you and I have
spoken about in the past manu and that's this notion of what
looks like 'jsonld processing' to a non-jsonld nerd is
completely different soeone who isn't speaking jsonld
<Zakim> Justin_R, you wanted to comment on "JSON LD Processing"
Justin_R: you have someone doing normal json web api stuff and
it has this context thing I need to look at and if I go digging
in that and it has this schema document.. it's going to feel
like I'm doing jsonld processing. Even if I"m not actually
doing that, it feels like a requirement beyond what is
intended. I believe the new text that says do a string
comparison, end of day, is a good move. But we need to not
stand on this bridge of "it's not really
jsonld processing" unless we want to be very explicit about the
phrase jsonld processing which isnot intutitive for people who
are not in the jsonld space full time
manu: +1
DavidC: I think it's more than this becuase you have to look at
the aliasing as well, the type is a URL but in our examples
it's not a URL
... the only way you know that our examples are URLs then you
have to do some @context processing
... the jsonld processor would say these types are not URLs
dlongley: I'm not sure I follow what david is saying. If your
app is written to understand specific contexts without having
to do any processing on those, only understands json, and you
write it against the rules in some spec somewhere that lists
the meaning of that context, you sholuld be just fine. Some
people decide to hardcode terms and keys to certain values in
their applications. All we're doing is calling out where the
semantic mappings and
defintions can be found in a context file if you want to go
into the json ld space and dereference those
scribe: but people can write applications with hardcoded values
without doing that
DavidC: when they come to extend they're going to say it's a
special type of VC..w hat are they goign to put in there? a URL
or a string? it's going to cause ag reat deal of
misunderstanding
... We either say you have to understand the aliasing mechanism
or you don't use it
<dlongley> this is becoming a discussion... need to take
offline
<Zakim> manu, you wanted to stop discussion.
DavidC: but to leave it in this grey world where you may or may
not use aliases or may hard code them or not, I feel it's
storing up problems for the future when we get people using
this down the line who are not familiar with all this
discussion
manu: we need to move on from discussion, we can't put forward
a proposal for this
... David, what it sounds like is a bunch of normative changes?
if you're not doing that we can add non-normative text, I've
got a proposal to explain that stuff. I believe you're
technically incorrect, but we need to probably have that
discussion because again as Justin said I don't think that you
understand at depth how jsonldp rocessors work
... one thing is we can have an offline discussion where we
talk about it more in depth. Or I can propose that we make non
normative text changes
DavidC: I am very happy with non-normaitve text changes. We are
using JSON and it needs to be undestandable to peopl ein that
mode
manu: you feel it's possible to create non-normative text that
helps with thatJ?
DavidC: we should certinaly have a go at it
manu: *reads a text change* .. the json-ld processing is far
more involved than if you do json only, which is just string
compares
... nothing was raised in the issue that changes the midn of
the group
... no normative changes, but we do admit we need to add
non-normative text text to underscore why not doing context
processing at all \(ie the string compare \) creates semantic
ambiguity
<manu> PROPOSED: Processing @context for both JSON-based and
JSON-LD-based processors is vital to ensure semantic
interoperability. The VCWG has considered the points raised in
issue #491 and has determined that no new information has been
provided with regard to the topic of semantic interoperability.
Additional non-normative text should be added to the
specification to underscore why not comparing the @context
against known values when using JSON processors leads to
semantic ambiguity.
manu: that's the proposal, anything folks want to add?
stonematt: any objections to this proposal?
RESOLUTION: Processing @context for both JSON-based and
JSON-LD-based processors is vital to ensure semantic
interoperability. The VCWG has considered the points raised in
issue #491 and has determined that no new information has been
provided with regard to the topic of semantic interoperability.
Additional non-normative text should be added to the
specification to underscore why not comparing the @context
against known values when using JSON processors leads to
semantic ambiguity.
<manu> [24]https://github.com/w3c/vc-data-model/issues/484
[24] https://github.com/w3c/vc-data-model/issues/484
manu: issue 484 is next
... this one is related to types
... tony is saying we should not be forced to use jsonld in the
type data model, it should allow for a json model such as jwts
and cwts, there are many parsers for those..
... so there's a lot of back and forth in this thread between
tony and brent and davidc
... a lot of explaination that goes on and then dlongley jumps
in .. 26+ comments
... tony is asking for these changes to the spec. Tony is
asking for, specifically..
<manu>
[25]https://github.com/w3c/vc-data-model/issues/484#issuecommen
t-479922835
[25] https://github.com/w3c/vc-data-model/issues/484#issuecomment-479922835
<Zakim> Justin_R, you wanted to discuss JSON LD semantics
manu: in that comment tony is saying no jsonld statements are
allowed. He says I don't thik this will work without changes to
the spec, so the spec should say no jsonld to be allowed, no
context to be allowed, document jwts to be allowed, jws to be
proof mechanisms, and says there will be other things that need
to be documented to allow jwts
Justin_R: there's a lot of comments in that thread but honestly
most of this boils down to be what has been one of my core
concerns bbotu this for a while in that it's pretending to not
use the jsonld based data model and in doing so peole coming
with their own data model that is similar to that are offput by
these half specified requirements to say oh well you need to
use this date field... I already have an expirationDate field
why would I use
yours? At the end of the day the reuqests for requirement
changes are smoke and mirrors. But the cause of these is valud
and needs to be addressed. In that, as I've been saying for a
bit, the spec needs to be more clear and up front about what
the data structure actually is and how things are epxressed in
such a way that they are translatable to and from that
scribe: manu your pr and my pr have sought to address that
although having read yours in the background, in very different
ways
... I do think this is a fundamental issue of understanding
what the spec is about but if people are reading the spec and
saying it looks like I sholud be able to just use my data model
here why are you telling me I can't, that's on us to be more
clear about what the requirements really are
... My suggestion is to as I've said to you on side
conversations is to stop pretending that it's more universal
than it is
... this is a jsonld based data structure which you can process
without using all the aliasing and dereferecing and all the
other stuff, but the core data structure is based on jsonld
schemas and constructs and we have to say that. Then you can
answer this issue with no i'ts this but if you can translate
from your carrier format for processing and out of it into your
carrier format then that's fine. My pr seeks to do that
<dlongley> +1 to Justin Richer's PR
<dlongley> +1 to say Justin Richer's PR addresses this issue
manu: you believe the group is working on this, we've got prs
in. Can we address this issue by saying we're adding
non-normative text to the spec to address this concern? once
the nonnormative text is in the spec we should close this issue
Justin_R: once the text is incorporated the issue should be
closed, but it's not being closed in thew ay requested by the
opener
... We need to be clear about what the spec wants
manu: if anyone thinks that we should remove json ld and
@context from the spec entirely please speak up
... we're attempting to clarify that jsonld is not mandated
... the issue is specifically about type, here's a proposal
<Justin_R> who's speaking?
<Justin_R> thanks
TallTed: microfocus on let's change this sentance within a
giant sphere that is itself problematic does not help us even
though we close issues that look like they're small
<Justin_R> +1 to TallTed's point
TallTed: everything I heard in this conversation is based on
jsonld structure. Requires this construct and that construct,
all of this is jsonld. If jsonld is mandatory then this is
based on jsonld, it is a derivative becuase it reuqires this
other thing
... there is definitely an issue there, coming at least form
this person talking about jwts and jws and other things. I have
a concern as well that it means there's no possibility for
future evolution among other things
... and that would kill the spec which is problematic, but
maybe that's the case
... there's a choice between let's ram this thing through, and
recognising that forcing a decision is problematic
<Zakim> Justin_R, you wanted to comment on what jsonld is
required :for:
Justin_R: I agree this is a broader discussion. I want to
reinforce my point that the key is being clear on what jsonld
is for in the spec
... when people say you need to understand jsonld to do this
bit and then people push back that you don't need it for
everything all the time, then you're talking at cross purposes
... if the spec can be clear about what it uses the technology
for, and how much you're required to understand (and the type
system is one of those) then it would be in much better shape
than to pretend those requirements of understanding ar enot
there
manu: we need *concrete* spec text
... the conversation has been very nebulous. We get it, boil it
down to concrete spec text
TallTed: that is not a functional response
manu: what would make you happy?
TallTed: I do not have an answer. Demanding concrete spec text,
the only answer I can say to that is strip out everything that
mentions jsonld if it is not actually mandatory. But it is
mandatory and cannot be stripped out so that won't get any
consideration from anybody
... this is one of those spaces where inertia is really
problematic
... there is text here that is in a concrete form. It has
problems. The solutions ot to those problems are not clear.
Because the solutions are not clear, concrete suggestions are
not possible
<DavidC> We need to agree on the concepts and the understanding
of them before we can produce concrete text
TallTed: We're in a stupid system hat mandates everything be
done in a prespecified time frame, and some things just aren't
doable that way
<Justin_R> +1
<manu> [26]https://github.com/w3c/vc-data-model/issues/485
[26] https://github.com/w3c/vc-data-model/issues/485
manu: Next up is issue 485
<manu> PROPOSED: The specification is not clear with respect to
the range of possible values for the issuer property and should
add a few non-normative examples of different values that can
be associated with the issuer property such as identifiers
associated with JWKs and DIDs as well as embedded values. Issue
#485 should be closed after the PR has been merged.
manu: about allowing the issuer to be a jwk. There has been
some discussion in that issue, a pr has been created and
reviewed by multiple parties indicating how a jwk can be
included. We have made modifications to the spec that
demonstrates how a jwk can be used
<Justin_R> @bigbluehat can you provide a link to information
about that forum?
manu: We have not doen the embedded value thing yet
<manu> PROPOSED: The specification is not clear with respect to
the range of possible values for the issuer property and should
add a few non-normative examples of different values that can
be associated with the issuer property such as identifiers
associated with JWKs and DIDs. Issue #485 should be closed
after the PR has been merged.
manu: there seems to be push back that he wasn't expecting that
to be ther eso we could strike that
stonematt: are we comfortable we won't get a new issue next
week about embedded values?
manu: I would expect there wouldn't be folloup, the commenter
has said they don't expect it to be used in that way
<manu> PROPOSED: The specification is not clear with respect to
the range of possible values for the issuer property and should
add a few non-normative examples of different values that can
be associated with the issuer property such as identifiers
associated with JWKs and DIDs. Issue #485 should be closed as
the PR has already been reviewed and merged.
stonematt: any objections?
oliver: no objections. I think there might be an easier way to
model it, to use jwk for a specific issuer. There's nothing
that prevents someone to use the native jwt claim an dheader
names to do that
... I have some issues understanding th eproposal but no
objections so it's fine
<Justin_R> @bigbluehat thanks, it's not letting me log in
though. I'll have to dig up details later
manu: technically tha'ts correct, it's just that the commenter
said they'd like to see that specific field support jwk
... it does, it's a URL, it can poitn to a jwk
oliver: all right
RESOLUTION: The specification is not clear with respect to the
range of possible values for the issuer property and should add
a few non-normative examples of different values that can be
associated with the issuer property such as identifiers
associated with JWKs and DIDs. Issue #485 should be closed as
the PR has already been reviewed and merged.
stonematt: not hearing any objections, proposal is resolved
manu: next is 486...
... *reads issue*
<stonematt> [27]https://github.com/w3c/vc-data-model/issues/486
[27] https://github.com/w3c/vc-data-model/issues/486
manu: brent has responded, oliver has responded, I have
responded and so has davidc
... both david and brent have put in PRs to address each one of
these items
... the proposal is that jwts are an external enveloping
digital sig format and cannot be embedded in data. Specifically
asking for jwts to be embeddable both at the top level and as
an embedded data format. You end up duplicating the
information. LDS uses JWS today as an embedded proof format.
That's not an official rec yet
encryptying digitally signs expressions is also supported by
the data model today
scribe: we can say that we've got prs in already
... issue 486 shoudl be closed after non normative changes
... we responded to every issue that he rasied by explaining
how the spec already supports it, or we made the one
nonnormative change we could
... brent you believe that?
... and considereda ll the things that were raised?
brent: i believe so. I don't know that it would make sense to
add more nonnoramtive text to the spec that addresses it
further. i don't feel tha tanything needs to happen. If someone
else feels strongly that does need to happen they should speak
up
<manu> PROPOSED: JWTs are an external/enveloping digital
signature format and cannot efficiently be embedded in data.
Encrypting digitally signed (and proofed) expressions of the
Verifiable Credentials Data Model are expected via the use of
JWEs, COSE, TLS, and other encryption mechanisms and a fully
supported by the Verifiable Credentials Data Model. Issue #486
should be closed after non-normative changes to the
specification are made #536.
DavidC: I was just playing devil's advocate and trying to look
at it from tony's perspective. It does seem odd the way we have
it. The proposal I made reverts to an earlier viersion of the
spec which would be a normative change. If we're not going to
havea new cr I can withdraw my proposal. But if we are having a
new CR I would like to re-look at my solution because I think
it would appease tony better
manu: given we don't have another CR yet would you be willing
to hold off on that PR until the point we hit another CR?
DavidC: Absolutely. I don't want this to be cause of another CR
... but if there is another CR because of something else I'd
like to look at this as well
manu: so, not an objection
stonematt: we have a proposal on the table, any objections?
RESOLUTION: JWTs are an external/enveloping digital signature
format and cannot efficiently be embedded in data. Encrypting
digitally signed (and proofed) expressions of the Verifiable
Credentials Data Model are expected via the use of JWEs, COSE,
TLS, and other encryption mechanisms and a fully supported by
the Verifiable Credentials Data Model. Issue #486 should be
closed after non-normative changes to the specification are
made #536.
<manu> [28]https://github.com/w3c/vc-data-model/issues/487
[28] https://github.com/w3c/vc-data-model/issues/487
manu: next up is 487
... the commenter has a general theme on many of the issues
that have been raised.. they're saying how can there be interop
if there is no standardised proof mechanism
... then suggesting that jws becomes that standardised proofing
mechanism
... fundamentally the disagreement is it looks like you're
creating a spec that needs a digital signature format, because
you have provided some digital signature formats in here that
don't have recommendations, I'm suggesting you rip those out,
or they're all non-onrmative - and to be clear, they're all
non-normative today, so we're doing what he is suggesting
... what we do allow for is a place where you can put embedded
digital sig formats like LDproofs LDS, all using that
mechanism, but we don't specify the details. All we specifify
are the extension points
... The assertion potentially based on the way the group is
operating is that we are definitng a set of extension points in
the spec, not the extensions themselves. that's out of scope of
the charter
... the commenter is saying why don't you make jwts the default
and that's it?
... currently there is normative language in the spec that
tells you exactly how to use a jwt and the data model together
... even for the nonnormative bits we use jws
... for the rsasignatures that we do in the LDproofs and LDS
implementations that exist today we are using jws
... all of this is to say the group needs to make a decision on
what the spec is
... and what it is intended to do
... are we doing data model with extension points? or are we
doing data model where every single extension point has to
demonstrate interop specifically around digital signature
formats?
... or are we saying (which is what I'm saying the group has
traditionally said) we are not picking a winner when it comes
to digital signature formats, we're mkaing sure all of them
could work even the ones that are nonnoramtive today because we
have a variety of companies doing a variety of proofs in
different ways
... that's the background
... the question in this issue is how can there be interop when
there's no standardised proof mechanism?
... one way we can respond is that we acknowledge that there
are as et of specs that are currently non normative and that
further standards work needs to be done on them
... eg. LDproofs LDS
... and that this work would benefit from that work contunining
in parallel outside of this group
... the other assertion we can make is that the spec is already
clear about how you can utilise jwwts and jws in the current
spec
... we can recommend that the spec is clear about how you use
jwts and jws. And we ack that there are non-norm signature
mechanisms and we recommend the reation of groups to work on
those
... any objection to a proposal along those lines?
<Justin_R> +1
DavidC: it's good we have these extension points. We can test
the type in the data model but we can't test the extensions.
What I don't like about the jwts is it doesn't use the
extension point, it doesn't say th eproof is type jwt. We've
made a special case for jwt. What happens if you want a mime
typ eor an x509 signature or something? how is that going to be
put in externally? I'd prefer we put in the way of doing jwt
using the extension points.
It's how we used to have it. And thenw e're consistent and
every proof is defined via the extension point
scribe: but now we've pulled jwt out as a speical loner
manu: we have discussed that before
jonathan_holt: we're getting into a lot of details about
validating signatures.. we can kick the can down the road
manu: I didn't hear any objections, I see a +1 from Justin
about what DavidC was saying. That's where we started. There's
an enormous amount of duplication when we take a JWT and put it
in the proof. We did have a discussion with mike jones and
other folks about how to embed the proof. THat's exactly how
the ?? works. The nonnormative thing already does what you're
saying we should do
... but that was not acceptable to some of the folks that were
suggesting jwts
... what we have in the spec is a result of those types of
discussions
... w e're doing what you want david, but that is not
acceptable to the folks pushing the jwts stuff
Justin_R: if we're not here to discuss things then I guess it's
done..
manu: is ther esomething we could push to another call?
Justin_R: nothing I could bring up now would be to fruitful
conversation and resolution
manu: would you like to change the context of the discussion?
Justin_R: we can move on
oliver: the reason we chose this approach was to make use of
existing jwts out there and try to be compliant with the jwt
spec, that's why we ended up having the jwt data model the way
it is now
... otherwise we woul dhave to have all information duplicated
which was not very efficient
manu: yep
... the spec is clear about jwts and the data model,t here are
normative statements around that. We're acknowledging that we
can't make normative statemetns but that the work could be
continues, and it would help a bunch of other specs too
... that closes the issue
... any objections to that sort of proposal?
<manu> PROPOSED: The specification is clear wrt. using JWT and
JWS with the VC Data Model. The VCWG acknowledges that a W3C
Recommendation for RDF Dataset Canonicalization, Linked Data
Proofs, and Linked Data Signatures does not exist, and that the
Verifiable Credentials Data Model specification, as well as a
number of Linked Data Working Groups at W3C, would benefit from
such a set of standards. The VCWG strongly recommends the
creation of a W3C Working Group to create such a set of W3C
Recommendations. This closes issue #487.
Justin_R: this ultimately boils down to what is the scope of
the document?
... given how much each of these issues have been coming up,
regardless of what happened to get to this point, more people
ar elooking at it, we need to consider these points. It is
unclear what the scope of the document truly is. If the
resolution is puttin gin more nonnormative text that says how
you do this is something else and not our problem then we need
to do that
... pretending there are extension points when there is
handwaving is not helpful to interop or the viability of the
spec
<TallTed> +1
<dlongley> +1 to clarifications to reach the intent
<scribe> scribenick: yancy
<oliver> could you share the PR again?
manu: agreed
<Justin_R> [29]https://github.com/w3c/vc-data-model/pull/539
[29] https://github.com/w3c/vc-data-model/pull/539
stone: which PR
... 539
<Justin_R> That's the bit about data primacy, it doesn't
address things at the root level of the spec about scope
<manu> PROPOSED: The specification is clear wrt. using JWT and
JWS with the VC Data Model. The VCWG acknowledges that a W3C
Recommendation for RDF Dataset Canonicalization, Linked Data
Proofs, and Linked Data Signatures does not exist, and that the
Verifiable Credentials Data Model specification, as well as a
number of Linked Data Working Groups at W3C, would benefit from
such a set of standards. The VCWG strongly recommends the
creation of a W3C Working Group to create
<manu> such a set of W3C Recommendations. Additionally,
non-normative text should be added to the specification that
suggests that data needs to be translated to/from the data
model, once this PR is in, issue #487 should be closed.
manu: any objections?
davidc: the proof should be there for jwt
<manu> PROPOSAL: The specification is clear wrt. using JWT and
JWS with the VC Data Model. The VCWG acknowledges that a W3C
Recommendation for RDF Dataset Canonicalization, Linked Data
Proofs, and Linked Data Signatures does not exist, and that the
Verifiable Credentials Data Model specification, as well as a
number of Linked Data Working Groups at W3C, would benefit from
such a set of standards. The VCWG strongly recommends the
creation of a W3C Working Group to create such a set of W3C
Recommendations. Additionally, non-normative text should be
added to the specification that suggests that data needs to be
translated to/from the data model and to pay particular
attention to the proof extension point, once this PR is in,
issue #487 should be closed.
manu: posts new proposal
... any objections?
RESOLUTION: The specification is clear wrt. using JWT and JWS
with the VC Data Model. The VCWG acknowledges that a W3C
Recommendation for RDF Dataset Canonicalization, Linked Data
Proofs, and Linked Data Signatures does not exist, and that the
Verifiable Credentials Data Model specification, as well as a
number of Linked Data Working Groups at W3C, would benefit from
such a set of standards. The VCWG strongly recommends the
creation of a W3C Working Group to create such a set of W3C
Recommendations. Additionally, non-normative text should be
added to the specification that suggests that data needs to be
translated to/from the data model and to pay particular
attention to the proof extension point, once this PR is in,
issue #487 should be closed.
<manu> [30]https://github.com/w3c/vc-data-model/issues/483
[30] https://github.com/w3c/vc-data-model/issues/483
manu: next up is 483. same one we attempted last week.
... johnny crunch and manu discussed on phone
... no reason to make in mandatory
... attempting language to address that right now
... don't make context mandatory
... versus json processing of it
... suggestion here is no change to the spec
... because it's already optional
... we can add clarifying text to the spec
... which is also being added because of other PRs
... we are not goting to remove at context processing from the
spec
<manu> PROPOSED: The VCWG had considered all points raised by
issue #483 throughout the lifetime of the WG's operation, no
new information was provided by issue #483 to convince the WG
to change @context being mandatory (which has broad support in
the WG with no objections). The WG will provide non-normative
changes to the specification to clarify when and how @context
should be processed and that "JSON-LD processing" is optional.
manu; there's the proposal
stone: any objections?
RESOLUTION: The VCWG had considered all points raised by issue
#483 throughout the lifetime of the WG's operation, no new
information was provided by issue #483 to convince the WG to
change @context being mandatory (which has broad support in the
WG with no objections). The WG will provide non-normative
changes to the specification to clarify when and how @context
should be processed and that "JSON-LD processing" is optional.
stone: resolved
<manu> [31]https://github.com/w3c/vc-data-model/issues/488
[31] https://github.com/w3c/vc-data-model/issues/488
manu: back to 488
... variation on the same argument
... tony is suggesting that presentation is at risk
... in conflict with previous arguments
... brent and tony have gone back and forth many times
... anything marked at risk are then removed
... this is an argument for the removal of presentation
... didn't mark at risk
... we ack that there are several different types of proofs and
provided a mechanism to provide more than one of those
... right now we use language that should be modified and we
need to clarify requirements
<manu> PROPOSED: Implementers were polled before the
specification entered the Candidate Recommendation phase and
more than two implementers stated that they would implement
this feature, thus it is not at risk. Interoperability for this
feature is achieved if at least two independent implementations
support the data model features in the specification, The WG
acknowledges that there are several different types of
zero-knowledge proof mechanisms and has provided a mechanism
where one or more of those mechanisms can be combined with the
data model in the specification. The group agrees that
non-substantive changes should be made to the section to
clarify the normative requirements more precisely and then
issue #488 should be closed after that PR is approved and
merged.
RESOLUTION: Implementers were polled before the specification
entered the Candidate Recommendation phase and more than two
implementers stated that they would implement this feature,
thus it is not at risk. Interoperability for this feature is
achieved if at least two independent implementations support
the data model features in the specification, The WG
acknowledges that there are several different types of
zero-knowledge proof mechanisms and has provided a mechanism
where one or more of those mechanisms can be combined with the
data model in the specification. The group agrees that
non-substantive changes should be made to the section to
clarify the normative requirements more precisely and then
issue #488 should be closed after that PR is approved and
merged.
stone: proposal resolved
<manu> [32]https://github.com/w3c/vc-data-model/issues/489
[32] https://github.com/w3c/vc-data-model/issues/489
<stonematt> Implementor List:
[33]https://drive.google.com/open?id=1SzfAUA0J72-1BORHJEmY4cdZr
Q6vmKy4oq_24r_NwB4
[33] https://drive.google.com/open?id=1SzfAUA0J72-1BORHJEmY4cdZrQ6vmKy4oq_24r_NwB4
amy can you scribe again?
<rhiaro> scribenick: rhiaro
manu: they're suggesting the removal of jsonld entirely since
it's not in a standards body... but it was ratified by w3c many
years ago.. there's an active json 1.1 wg right now, the
commenter may be unaware that it wwent to through the
standardisation procses twice now. But they want tha tproofs
are marked as risk because there's no interoprable
recommendation. We realised that the extension point we are
demonstrating is the proof extension point,
and we can't say anything about it until those things become
recs. But there have been multiple iplementors who say they'll
support that part of the data model
scribe: the test suite will have non required tests to
demonstrate ldproof interop, but we can't make them official
tests because they're not recommendations
... we could respond with the VCWG does not support the removal
of jsonld from the spec
... specifically for section 4.7, interop is defined by two
implementations implementing the normative statements in the
section
... we do have normative statements in there on how you
identify the type of proof in the extension points. The VCWG
does not believe it's not appropriate to make this section
non-normative. We need to make sure you can identify the type
of proof that' sused. The suggestion is to close the issue with
no change to the spec
<manu> PROPOSED: The VCWG does not support the removal of
JSON-LD from the specification. For Section 4.7: Proofs,
interoperability is defined as at least two implementations
implementing the normative statements in the section.
Specifically, that the data model specifies a mechanism to
express an embedded proof and the type of proof. The VCWG does
not believe that it is appropriate to make this section
non-normative. Issue #489 should be closed with no change to
the specification.
stonematt: any objections?
... hearing none
RESOLUTION: The VCWG does not support the removal of JSON-LD
from the specification. For Section 4.7: Proofs,
interoperability is defined as at least two implementations
implementing the normative statements in the section.
Specifically, that the data model specifies a mechanism to
express an embedded proof and the type of proof. The VCWG does
not believe that it is appropriate to make this section
non-normative. Issue #489 should be closed with no change to
the specification.
<jonathan_holt> were there any other issues that need me? I
need to drop off
<manu> [34]https://github.com/w3c/vc-data-model/issues/496
[34] https://github.com/w3c/vc-data-model/issues/496
manu: next up is expiration, 496
... suggestion is values like expiration date should be changed
to match jwts
... *reads issue*
... brent's response is a VC is not a JWT. JWTs can encapsulate
VCs, but are not in and of themselves VCs
... the other assersion that olive rmade is that the
serialisation, the values associated with exp and
expirationdate are different
... there's a section in the spec that tells you how to convert
between the two
... tony says all existing jwt claims should be allowe dfor
interop. There's a section in the spec that expresses how you
express this stuff using a jwt that does not limit any jwt
claim used today
<Zakim> Justin_R, you wanted to discuss JWTs vs. VC
Justin_R: I keep saying this but if we are clear about the fact
that th eprocessing of the semantic document require that dates
be converted to a specific structure for comparison in the case
of expiration, for any other addition math or whatever, all of
these data values need to live in a data model in a specific
place and all serialisations must have fully spec'd and
determinisitc translations into and out of that data model
... then the data model becomes the semantic interlingua? for
all of the syntactic serialisations
... if you say the data model uses jsonld dates, that's fine
... the problem is that there are serialisation formats people
want to use that have their own date formats. You want to say
yes you can do that, and that's okay for processing hte jwt but
not for processing the VC as a VC
... you need to translate into this other thing
... if I"m going to speak jwts it's going to need a vc.parse
that takes a jwt in and spits out a vc object
<dlongley> it's not a "JSON-LD" date (btw)... it's RFC3339,
JSON-LD doesn't define "dates" ... but yes, we do say RFC3339
for the issuanceDate property.
<oliver> +1
Justin_R: if that vc object where all of the holder proofing
happens, but when I got to validate the proofing signature that
goes back to the original jwt and it's validation fields. These
are not incompatible with each other, but it's a matter of
saying what the document is specifying which is a semantic data
structure and not a specific syntax
... and that the syntaxes are translations of that
<DavidC> +1
manu: how do we turn that into something concrete? doe syour pr
do that? or we need a new pr
Justin_R: your pr does not do that, my pr is my best attempt at
that
... I'm open to comments to make my pr better
manu: if we said we're going to address this issue by
effectively pulling in your pr, my pr or some combination
thereof, you'd feel this issue was addressed?
Justin_R: yes, addressed in a way that we are saying no we're
not just going to use the exp field and posix dates which is
what you've said in the comment thread on that issue
... but we are saying if you have date fields and you translate
them into posix dates, as long as you can do that without data
loss (deterministic and bidirectional) and then on the other
end you can translate it back into an actual data object that
someone can do comparisons on, then we're fine
<manu> PROPOSED: Re-using the JWT "exp" claim in a Verifiable
Credential is not appropriate because the datatype associated
with JWT "exp" is a POSIX time value and the datatype
associated with the expirationDate is a RFC3339 combined date
and time string. The VCWG prefers the more verbose datatype.
Non-normative text should be added to the specification on how
deterministic and bi-directional translation should be done and
issue #496 should be closed after that PR is merged into the
specification.
stonematt: any objections?
... hearing none
RESOLUTION: Re-using the JWT "exp" claim in a Verifiable
Credential is not appropriate because the datatype associated
with JWT "exp" is a POSIX time value and the datatype
associated with the expirationDate is a RFC3339 combined date
and time string. The VCWG prefers the more verbose datatype.
Non-normative text should be added to the specification on how
deterministic and bi-directional translation should be done and
issue #496 should be closed after that PR is merged into the
specification.
<manu> [35]https://github.com/w3c/vc-data-model/issues/500
[35] https://github.com/w3c/vc-data-model/issues/500
manu: next up is status.. 500
... the mention of the status registry, who runs it, why isn't
it iana? is the question
... those questions were answered, there's another issue that
says we should have an extension point registry. The group
seems to be pushing that over to the CCG to manage that
... that's where the current proposal is, the ccg will maintain
it
... Why not iana? At this point the group doesn't feel like we
need to go to those lengths but we may change our mind later on
or others may move it to iana in the future, currently we want
it to be very lightweight
... w3c is already working on a registry mechanism through th
eAC and we're supposed to talk with chaals about that
... that kind of addresses the why/who is running it question
... The other question is how will interop be achieved if these
are not standardised in a registry accessible to all
implementations
... it is accessible, it's an html link that anyone can follow
... then he says the data model doesn't need to exist. Don't
understand the logic there. But he's saying 4.9 status sholud
be marked at risk because there's no nonnormative solutions for
it and interop cannot be shown on the mechanism
... THe response we can have is that we have defined an
extension point and your requirement, the normative statement
is that you're required to express the type information that's
associated with the status mechanism
... So effectively no change to the spec
... Given the other suggestiosn in the other prs that are we're
going to make it very clear that we're trying to specify the
extension points, not every single extension that could be used
<manu> PROPOSED: The VCWG has delegated the management of all
extension registries associated with the Verifiable Credentials
Data Model to the W3C Credentials Community Group in order to
support continuity in the extension work as well as a ensuring
a light-weight process for managing the registry. The W3C is
incubating a registry process as well, and we are in
discussions with the Advisory Board on that. The VCWG believes
that this approach strikes the right balance of formalism and
flexibility at this stage of the specifications deployment into
the market. With respect to the 'status' field, the group has
defined an extension point and a mechanism to identify specific
extensions, which are the normative statements in that section.
Issue #500 should be closed with no changes to the
specification.
stonematt: any objections?
RESOLUTION: The VCWG has delegated the management of all
extension registries associated with the Verifiable Credentials
Data Model to the W3C Credentials Community Group in order to
support continuity in the extension work as well as a ensuring
a light-weight process for managing the registry. The W3C is
incubating a registry process as well, and we are in
discussions with the Advisory Board on that. The VCWG believes
that this approach strikes the right balance of formalism and
flexibility at this stage of the specifications deployment into
the market. With respect to the 'status' field, the group has
defined an extension point and a mechanism to identify specific
extensions, which are the normative statements in that section.
Issue #500 should be closed with no changes to the
specification.
stonematt: how do we want to follow up on the discussions that
were postponed to be continued offline?
<DavidC> Can we fix up a date and time now
manu: let's see if people are available tomorrow. Justin,
David, brent, do you have availability tomorrow?
... after 12pm ET?
<DavidC> Yes I am free all day tomorrow
brent: i have extremely limited availability through to the end
of this week
manu: what is your availability?
brent: i'd have to get backt o you
manu: any days we should avoid for all of you?
<DavidC> Friday is no good for me
Justin_R: My schedule is not clear
ken: I can accommodate
manu: looks like it'll be wednesday/thursday
<DavidC> Thursday early for you is good for me
manu: we'll send out an email, everyone can attend
stonematt: would you list the prs we might discuss? refresh
service wa sa huge topic
... Thanks everyone
... bye
Summary of Action Items
Summary of Resolutions
1. [36]Processing @context for both JSON-based and
JSON-LD-based processors is vital to ensure semantic
interoperability. The VCWG has considered the points raised
in issue #491 and has determined that no new information
has been provided with regard to the topic of semantic
interoperability. Additional non-normative text should be
added to the specification to underscore why not comparing
the @context against known values when using JSON
processors leads to semantic ambiguity.
2. [37]The specification is not clear with respect to the
range of possible values for the issuer property and should
add a few non-normative examples of different values that
can be associated with the issuer property such as
identifiers associated with JWKs and DIDs. Issue #485
should be closed as the PR has already been reviewed and
merged.
3. [38]JWTs are an external/enveloping digital signature
format and cannot efficiently be embedded in data.
Encrypting digitally signed (and proofed) expressions of
the Verifiable Credentials Data Model are expected via the
use of JWEs, COSE, TLS, and other encryption mechanisms and
a fully supported by the Verifiable Credentials Data Model.
Issue #486 should be closed after non-normative changes to
the specification are made #536.
4. [39]The specification is clear wrt. using JWT and JWS with
the VC Data Model. The VCWG acknowledges that a W3C
Recommendation for RDF Dataset Canonicalizatioe, Linked
Data Proofs, and Linked Data Signatures does not exist, and
that the Verifiable Credentials Data Model specification,
as well as a number of Linked Data Working Groups at W3C,
would benefit from such a set of standards. The VCWG
strongly recommends the creation of a W3C Working Group to
create such a set of W3C Recommendations. Additionally,
non-normative text should be added to the specification
that suggests that data needs to be translated to/from the
data model and to pay particular attention to the proof
extension point, once this PR is in, issue #487 should be
closed.
5. [40]The VCWG had considered all points raised by issue #483
throughout the lifetime of the WG's operation, no new
information was provided by issue #483 to convince the WG
to change @context being mandatory (which has broad support
in the WG with no objections). The WG will provide
non-normative changes to the specification to clarify when
and how @context should be processed and that "JSON-LD
processing" is optional.
6. [41]Implementers were polled before the specification
entered the Candidate Recommendation phase and more than
two implementers stated that they would implement this
feature, thus it is not at risk. Interoperability for this
feature is achieved if at least two independent
implementations support the data model features in the
specification, The WG acknowledges that there are several
different types of zero-knowledge proof mechanisms and has
provided a mechanism where one or more of those mechanisms
can be combined with the data model in the specification.
The group agrees that non-substantive changes should be
made to the section to clarify the normative requirements
more precisely and then issue #488 should be closed after
that PR is approved and merged.
7. [42]The VCWG does not support the removal of JSON-LD from
the specification. For Section 4.7: Proofs,
interoperability is defined as at least two implementations
implementing the normative statements in the section.
Specifically, that the data model specifies a mechanism to
express an embedded proof and the type of proof. The VCWG
does not believe that it is appropriate to make this
section non-normative. Issue #489 should be closed with no
change to the specification.
8. [43]Re-using the JWT "exp" claim in a Verifiable Credential
is not appropriate because the datatype associated with JWT
"exp" is a POSIX time value and the datatype associated
with the expirationDate is a RFC3339 combined date and time
string. The VCWG prefers the more verbose datatype.
Non-normative text should be added to the specification on
how deterministic and bi-directional translation should be
done and issue #496 should be closed after that PR is
merged into the specification.
9. [44]The VCWG has delegated the management of all extension
registries associated with the Verifiable Credentials Data
Model to the W3C Credentials Community Group in order to
support continuity in the extension work as well as a
ensuring a light-weight process for managing the registry.
The W3C is incubating a registry process as well, and we
are in discussions with the Advisory Board on that. The
VCWG believes that this approach strikes the right balance
of formalism and flexibility at this stage of the
specifications deployment into the market. With respect to
the 'status' field, the group has defined an extension
point and a mechanism to identify specific extensions,
which are the normative statements in that section. Issue
#500 should be closed with no changes to the specification.
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [45]scribe.perl version 1.154 ([46]CVS log)
$Date: 2019/04/16 13:39:48 $
[45] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[46] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 16 April 2019 13:42:34 UTC