W3C

- DRAFT -

Verifiable Claims Working Group Meeting

09 Apr 2019

Agenda

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


<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

PR Review

<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

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> 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

Summary of Action Items

Summary of Resolutions

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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 scribe.perl version 1.154 (CVS log)
$Date: 2019/04/16 13:39:48 $