<manu> scribenick: rhiaro
<stonematt> 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
<stonematt> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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
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> 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> 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> 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> 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> 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> 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> 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> 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> 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> https://github.com/w3c/vc-data-model/issues/489
<stonematt> Implementor List: 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> 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> 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