14:39:49 <RRSAgent> RRSAgent has joined #vcwg-special
14:39:53 <RRSAgent> logging to https://www.w3.org/2023/06/13-vcwg-special-irc
14:39:54 <Zakim> RRSAgent, make logs Public
14:39:55 <Zakim> please title this meeting ("meeting: ..."), ivan
14:40:09 <ivan> Meeting: Verifiable Credentials Working Group Special Topic Call on the Normativeness of Vocabulary and Context
14:40:09 <ivan> Date: 2023-06-13
14:40:09 <ivan> chair: brent
14:40:09 <ivan> Agenda: https://www.w3.org/events/meetings/f6342df0-f7b5-4fc9-babd-61e55dc5fc2f/20230613T110000
14:40:09 <ivan> ivan has changed the topic to: Meeting Agenda 2023-06-13: https://www.w3.org/events/meetings/f6342df0-f7b5-4fc9-babd-61e55dc5fc2f/20230613T110000
14:58:54 <ivan> present+
14:59:01 <ivan> present+ TallTed
15:00:15 <hsano> hsano has joined #vcwg-special
15:00:21 <shigeya> present+ shigeya
15:00:26 <ivan> present+ brent
15:00:38 <ivan> present+ shigeya
15:00:44 <hsano> present+
15:00:51 <brent> brent has joined #vcwg-special
15:00:54 <mprorock> mprorock has joined #vcwg-special
15:00:57 <mprorock> present+
15:01:17 <ivan> present+ PaulDietrich
15:01:55 <andres> andres has joined #vcwg-special
15:01:59 <andres> present+
15:02:04 <ivan> present+ smccown
15:02:20 <ivan> present+ selfissued
15:02:43 <brent> present+
15:02:57 <ivan> present+ kristina
15:03:10 <ivan> present+ dlongley
15:03:10 <selfissued> selfissued has joined #vcwg-special
15:03:11 <selfissued> present+
15:03:13 <ivan> present+ manu
15:03:24 <Paul_Dietrich_GS1> Paul_Dietrich_GS1 has joined #vcwg-special
15:03:47 <mprorock> scribe+
15:03:56 <smccown> smccown has joined #vcwg-special
15:04:00 <manu> manu has joined #vcwg-special
15:04:04 <manu> present+
15:04:12 <smccown> present+
15:04:15 <Will> Will has joined #vcwg-special
15:04:22 <ivan> present+ WillAbramson
15:04:23 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1103
15:04:58 <dlehn> present+
15:05:40 <mprorock> ivan: introduces topic - vocab vs context, starting with vocab being normative or not
15:05:54 <Orie_> Orie_ has joined #vcwg-special
15:05:55 <Orie_> present+
15:06:40 <mprorock> ... in the case of linked data and the ld point of view, urls and terms must be assigned, in addition relationships, etc
15:06:58 <dmitriz> dmitriz has joined #vcwg-special
15:07:16 <decentralgabe> decentralgabe has joined #vcwg-special
15:07:18 <mprorock> ... the current vcdm document describes the terms and semantics, and the vocab describes these as well as additional
15:07:20 <decentralgabe> present+
15:07:27 <dmitriz> present+
15:07:58 <Orie_> +1 ivan, vocabulary needs to be normative, if implementers are required to understand it
15:07:58 <mprorock> ... what i think is that the vcdm is obviously normative, and the vocab should also be normative, though in practice that is not always the case
15:07:58 <DavidC> DavidC has joined #vcwg-special
15:08:04 <DavidC> present+
15:08:30 <Orie_> if implementers don't understand it, they don't use those terms, then they don't get interop... this proves the document needs to be normative.
15:08:30 <mprorock> ... the html generated from the vocab need not be normative
15:09:15 <mprorock> ... the same principle should be used for the security vocab
15:09:20 <Orie_> +1 ivan, we need to discuss vocabulary for all TR track items.
15:09:45 <mprorock> ... with the small diff that some terms in the security vocab may be defined in another spec, but it should still be normative
15:10:00 <mprorock> ... the other question is the context - this is more complicated
15:10:05 <JoeAndrieu> JoeAndrieu has joined #vcwg-special
15:10:18 <ivan> https://github.com/w3c/vc-data-model/issues/1103#issuecomment-1545648125
15:10:53 <mprorock> ... from a purely theoretical point of view the context is just a transformation tool and does not define anything other than a mapping between urls and terms
15:11:12 <mprorock> ... continue to hold the opinion that it should not define anything
15:11:27 <mprorock> ... and that anything in the context should be present in the vcdm or the vocab
15:11:36 <Orie_> context has normative statements associated... https://w3c.github.io/vc-data-model/#contexts ... meaning the context is what connects "compact json-ld" to the normative vocabulary.
15:12:17 <mprorock> ... the context contains mapping between definitions of terms defined both in the wg and on the web at large in other well known vocabs
15:12:37 <mprorock> ... there is discussion on the other hand that the context should be normative
15:13:01 <Orie_> +1 to making context normative, especially given the trend to include status list and other normative term definitions in it
15:13:01 <mprorock> ... the ld world does not require the context, but it is helpful on the pure json level
15:13:26 <mprorock> ... there is a statement in the vcdm that points to the context normatively
15:13:59 <Orie_> +1 ivan, there are normative statements associated with `@context`, which means we are *assuming* that the underlying value does not change... but we know that is possible, unless we make the value normative.
15:14:00 <mprorock> ... the spec might actually point in the informative section
15:14:16 <shawnb> shawnb has joined #vcwg-special
15:14:18 <manu> q+ to ask "if we make one/both normative, how do implementations change?"
15:14:19 <mprorock> ... but does refer to the url and the hash of the context so that it is clear which version is included
15:14:23 <shawnb> present+
15:14:35 <mprorock> ... i would be happy if that statement were normative
15:14:50 <mprorock> ... bc it makes it stronger / more clear as to use of the context and which context
15:14:51 <Orie_> iirc, the hash part is currently not normative, but I agree with the comment that it might make things clearer... it seems like making the value normative is a more direct solution though.
15:15:32 <dlongley> +1 to make a JCS-canonized hash value of the context normative and allow for changes to the context during CR to address concerns around minor tweaks that may be needed to be responsive to implementations
15:15:35 <manu> q+ to note the danger of making both context and vocab normative (and how to get around it)
15:15:53 <mprorock> q+
15:16:06 <brent> ack manu
15:16:06 <Zakim> manu, you wanted to ask "if we make one/both normative, how do implementations change?" and to note the danger of making both context and vocab normative (and how to get around it)
15:16:30 <mprorock> manu: the general question for the group is that if we make either or both normative, what changes on the implementation side
15:16:51 <mprorock> ... the concern is that the stuff in the context might change, and we don't give directions around that
15:16:59 <Orie_> q+ to comment on how implementations would change
15:17:04 <dlongley> https://w3c.github.io/vc-data-model/#base-context
15:17:21 <dlongley> https://w3c.github.io/vc-data-model/#contexts
15:17:38 <mprorock> ... one option is to lock everything in with a normative statement and a hash
15:17:45 <dlongley> +1 to manu
15:18:01 <mprorock> ... as far as vocab being normative we are not sure what will change there, and a lot of tests to validate that
15:18:32 <Orie_> sounds like making a hash normative is just a shortcut for writing more tests.
15:18:32 <mprorock> ... want clarity on what is normative - the static representation, the tests, etc
15:18:58 <mprorock> ... not aware of other working groups stating this in the way that we are discussing
15:19:12 <Orie_> +1 to issue markers.
15:19:19 <dlongley> +1 to manu and issue markers
15:19:25 <mprorock> ... there is a change that if we need any changes that we will need to note that things will break
15:19:30 <mprorock> ... during cr
15:19:34 <manu> scribe+
15:19:39 <brent> ack mprorock
15:19:58 <mprorock> https://github.com/w3c/vc-data-model/pull/1140/files
15:20:28 <manu> mprorock: I see the multiple sides to this issue. I wanted to highlight something. I opened a PR on how to hash a context, expanded to something it wasnt intended to. If we are going to define how this is done, we should take this into account.
15:21:13 <manu> mprorock: Do we make this normative or not, if we are insistent on well-formed JSON-LD data model, if we can, we should try to make assets that go along with that as close to normative as possible, if we can make it normative (even in a simpler way), aspects from normative vocab, that might be a good path.
15:21:34 <manu> mprorock: I do want to understand what the implementation concerns are... this is the 2.0 WG, I don't mind if we have to change implementations to match up with what WG decides.
15:21:34 <brent> ack Orie_
15:21:34 <Zakim> Orie_, you wanted to comment on how implementations would change
15:21:48 <mprorock> Orie_: want to comment on how impl might change
15:22:14 <mprorock> ... in did core we had lots of context changes - typically via an at-vocab
15:22:37 <manu> q+ to focus on has or URL is normative, that feels like a productive path.
15:22:53 <mprorock> ... but certainly if there is not a set context, and hash, etc then we should expect manipulation or changes
15:23:20 <mprorock> ... addition of terms by the developer can be a feature or a bug depending on your perspective
15:23:31 <mprorock> ... hash seems worthy of exploring
15:23:32 <brent> ack manu
15:23:32 <Zakim> manu, you wanted to focus on has or URL is normative, that feels like a productive path.
15:23:45 <dlongley> +1 to the hash approach -- and we should consider whether we think using JCS on the content prior to hashing is necessary or helpful
15:23:49 <mprorock> manu: want to agree with a focus on hashing and statement as to url and hash
15:24:18 <ivan_> ivan_ has joined #vcwg-special
15:24:28 <Orie_> making the hash normative, makes w3id.org and schema.org term definitions normative, by proxy.
15:24:31 <mprorock> ... think that this makes things easier, and lets us test stuff cleanly, while also preventing dns poisoining, domain takeover, etc
15:24:55 <mprorock> ... could add a statement that first context must be a link with such and such hash
15:24:57 <dlongley> +1 to explicitly tell implementers they should not load the context from the Web once they have their own copy as it will not change
15:24:57 <Orie_> and for the record the hash being normative does not do anything regarding the URLs and their governance model, that are contianed in it
15:25:03 <mprorock> ... can do the same with vocab
15:25:18 <mprorock> ... not sure that that would change things for implementation
15:25:33 <Orie_> schema.org, w3c and w3id.org can still be bought / sold / transferred or compromised, regardless of if the hash does not change.
15:25:35 <dlongley> q+
15:25:36 <mprorock> ... believe that that would address concerns there - are there other concerns
15:25:45 <brent> ack dlongley
15:25:54 <Orie_> -1 to JCS.
15:25:56 <mprorock> dlongley: something we may want to consider is jcs prior to hash
15:25:57 <mprorock> q+
15:26:11 <mprorock> ... this would prevent possible issues with whitespace, etc
15:26:26 <mprorock> ... otherwise be careful that files don't change
15:26:30 <Orie_> just publish the document at a w3c origin, and publish its hash along side it.
15:26:39 <Orie_> no need for JCS.
15:26:47 <dlongley> Orie_: i'm happy if that's true for all time :)
15:26:49 <mprorock> ivan: requests quick summary
15:27:06 <mprorock> brent: normative approach to provide a hash and link to to context
15:27:18 <ivan_> q+
15:27:19 <Orie_> if we don't trust W3C to not tamper with documents, we should not use them to publish standards.
15:27:27 <brent> ack mprorock
15:27:35 <manu> mprorock: I'm happy to let Ivan go first.
15:27:38 <brent> q+ mprorock
15:27:42 <brent> ack ivan_
15:27:44 <dlongley> Orie_: W3C changes documents all the time in non-normative ways.
15:28:08 <mprorock> ivan_: find with context and hash - keep to opinion that vocab should be normative
15:28:28 <mprorock> ... the level of tests would not be burdensome if we made vocab normative
15:28:51 <manu> q+ to ask what making the "vocabulary normative" means?
15:28:58 <mprorock> ... let alone that the way things would be set on the vocab would point back to normative spec
15:29:27 <mprorock> ... changing vocab would require wg consensus
15:29:37 <mprorock> ... cannot just fiddle at will
15:29:40 <manu> q+ to ask if we need range checks and domain checks if we make vocab normative?
15:29:46 <mprorock> ... which is not necessarily the case for the context
15:29:49 <brent> ack mprorock
15:30:14 <manu> mprorock: Appreciate Ivan adding clarification to have vocab point back to core data model spec, helpful in general, good exploitation of LD in general.
15:31:13 <manu> mprorock: I know JCS was brought up, DNS poisoning, domain take overs, we should try to keep things inline w/ subresource integrity... base64url vs base64, dealing w/ exchange over the wire, pros/cons to both... something to be aware of, actual hash representation should be aligned w/ SRI specification at W3C.
15:31:21 <Orie_> dlongley we are assuming the W3C will not break context documents by changing them
15:31:22 <brent> ack manu
15:31:22 <Zakim> manu, you wanted to ask what making the "vocabulary normative" means? and to ask if we need range checks and domain checks if we make vocab normative?
15:31:37 <dlongley> Orie_: yes, we are (if we don't do JCS).
15:31:46 <ivan_> q+
15:31:49 <Orie_> No we are not.
15:31:59 <mprorock> manu: concerned re certain items in vocab that might become normative statements like range of domain and similar
15:32:02 <dlongley> Orie_: No, I'm agreeing with you. "We are assuming...".
15:32:19 <mprorock> ... pointing definitions to vocab are a good idea
15:32:36 <mprorock> ... putting a hash on it gives a concrete item to go check in a simple manner
15:32:44 <Orie_> Yes, assuming W3C doesn't mutate published standards is a given i think... if they mutate context values, we can't use them to serve them.
15:32:52 <mprorock> ... not sure if it is important for impl to go check above and beyond
15:33:00 <brent> ack ivan_
15:33:22 <mprorock> ivan_: i think the way to keep things together is that range etc fall outside scope of group
15:33:59 <Orie_> +1 ivan
15:34:04 <mprorock> ... if there are statements in the vocab that fall outside the vcdm then there is an issue since they are not normatively defined by the vcdm
15:34:15 <mprorock> +1 ivan
15:34:16 <Orie_> huge +1 to that point.
15:34:21 <manu> q+
15:34:30 <brent> ack manu
15:34:47 <Orie_> +1 to testing normative requirements
15:34:50 <mprorock> manu: concern not around discrepancies, concerns around stuff we are not testing today
15:34:59 <Orie_> q+
15:35:01 <mprorock> ivan_: if they are in vcdm we should test them
15:35:21 <mprorock> manu: notes that we will have to add tests for coverage, especially data types, ranges, etc
15:35:30 <mprorock> ... not sure how we test that
15:35:53 <mprorock> ... concerned that each impl may have to generate nquads
15:35:56 <dmitriz> +1 to what manu is saying, I don't see how we can test the vocab...
15:36:10 <Orie_> if we say compact JSON-LD and we don't test that... you can get different nquads... from different implementations.
15:36:36 <Orie_> +1 ivan, normative statements need to be tested... how they are tested is different topuc
15:36:43 <mprorock> ivan_: the vcdm does state that there are constraints on values normatively - question is do we test or not - nquards are irrelevant - we can test a multitude of ways
15:36:46 <dmitriz> q+
15:36:50 <mprorock> +1 ivan
15:36:56 <brent> ack Orie_
15:37:24 <manu> q+ to note that the only way to test this is via Data Integrity.
15:37:39 <mprorock> Orie_: we did resolve something we didn't have last time is that the base media type is compact json-ld which means that unless there are additional normative requirements we don't have to test to the level being suggested
15:37:47 <mprorock> ... completely agree with ivan
15:38:14 <mprorock> ... the normative statements in the current doc are in conflict with how we can test things
15:38:34 <manu> q+ to note the hashed value as the way to save us a lot of testing pain.
15:38:45 <mprorock> ... the hash approach might be a workaround for this, but we can't mix normative statements pointing to urls that are not covered under the core data model
15:38:55 <brent> ack dmitriz
15:38:57 <mprorock> ... we need to solve these normative issues one way or the other
15:39:18 <mprorock> dmitriz: want to push back that vocab is primary normative artifact
15:39:54 <mprorock> ... json-ld means that the vocab may not need to exist, bad practice of course, but it can work
15:40:05 <mprorock> ... we should define these terms somewhere
15:40:20 <mprorock> ... but if we don't define a vocab things don't break
15:40:27 <brent> ack manu
15:40:27 <Zakim> manu, you wanted to note that the only way to test this is via Data Integrity. and to note the hashed value as the way to save us a lot of testing pain.
15:40:32 <Orie_> if nothing breaks, the context is normative... and its integrity is normative.
15:40:38 <mprorock> manu: +1 to dmitriz
15:40:57 <mprorock> ... one thing that we could do is a data integrity transform and see if sigs match
15:41:04 <mprorock> q+
15:41:11 <dmitriz> @Orie - and I agree. I think the context is normative.
15:41:11 <Orie_> you can test to see if a files bytes has changed without converting the object to nquads.
15:41:37 <mprorock> ... all of this goes back to the context though, and that feels like something we should definitely test, and we should make sure that the context is integrity protected
15:41:38 <Orie_> and you can't use data integrity proofs to secure json-ld contexts.
15:41:41 <ivan_> q+
15:41:49 <mprorock> ... the vocab is for machine reasonaing and humans
15:42:02 <mprorock> ... feels like context and hash are an important thing
15:42:13 <mprorock> ... not sure how to test if we make vocab normative
15:42:31 <brent> q+ to ask what the normative statement would be
15:42:35 <brent> ack mprorock
15:42:50 <Orie_> for all terms in the vocabulary, there must be a human readable definition for the term, the term may be defined by w3id.org, w3c, or schema.org.
15:42:59 <manu> mprorock: -1 to add stuff from elsewhere vs. just checking hashes. Have the resource and then the hash to the resource. You do want to detect those changes.
15:43:34 <manu> mprorock: As for testing vocab, agree with Manu -- ensuring context is normative is important, perhaps hash to context and hashes to other versions that come from that, like schema.org.
15:43:41 <Orie_> -1 to bundling external contexts by reference... makes development harder.
15:43:48 <manu> mprorock: Regarding testing on vocab, there might be approaches there.
15:44:00 <Orie_> and makes integrity checking harder.
15:44:01 <kristina> kristina has joined #vcwg-special
15:44:28 <manu> mprorock: If we say something has certain parameters, value of certain shape, we have to test for it. Does it mean more work, it's something we have to do.
15:44:32 <brent> ack ivan_
15:45:00 <mprorock> ivan_: good to assign a hash < i think, garbled >
15:45:35 <mprorock> HAVING TROUBLE UNDERSTANDING
15:45:46 <Orie_> +1 to ivan, if the working group is publish a TR for a JSON-LD media type, we should do a proper job.
15:46:37 <mprorock> ivan could you summarize in chat so we don't loose it
15:46:50 <brent> ack brent
15:46:50 <Zakim> brent, you wanted to ask what the normative statement would be
15:47:08 <ivan_> What I wanted to say: if the consensus of the WG is that the vocabulary is referred to and is 'secured' via a hash, I will not lie down on the road on that
15:47:18 <Orie_> q+ to clarify
15:47:21 <mprorock> brent: concerns around testing - what i have heard is no opposition to a link to vocab / context and hash for each and normative statements that those match
15:47:28 <mprorock> ... sounds like folks are fine with that
15:47:43 <mprorock> ... going beyond that, concerns appear to be how would we test
15:48:05 <mprorock> ... my concern is what would the normative statements be - are those in vocab itself, etc
15:48:06 <brent> ack Orie_
15:48:06 <Zakim> Orie_, you wanted to clarify
15:48:29 <mprorock> Orie_: think i heard: there are normative statements that should be testable
15:48:54 <brent> that is what I understand
15:49:06 <mprorock> ... think that i also heard that there should be a normative statement that includes the hash
15:49:28 <mprorock> ... question on the vocab side is interesting, since we need to make sure that the statements are testable
15:50:04 <mprorock> ... some suggested language might look like an assertion that terms defined in TR appear in vocab as well, and that some terms may be defined externally
15:50:33 <mprorock> ... if we dont make vocab normative, but make context normative, we make vocab normative by reference
15:50:46 <mprorock> +1 to norm by ref, so lets make it good
15:50:48 <mprorock> q+
15:51:01 <brent> ack mprorock
15:51:21 <manu> mprorock: Possible language for a first proposal would be that we would normatively define URL for both context and vocab and provide hash that must be included.
15:51:48 <manu> mprorock: I am also happy to pull #1140, core context hash in there, add additions to there or add separately, that's the key thing.
15:51:56 <manu> manu: -1 to tying this to 1140.
15:52:14 <manu> mprorock: We should follow model set by subresource integrity and use that mechanism if multiple hashes are provided.
15:52:47 <mprorock> brent: is there anyone that wants changes or alternates to that proposal
15:52:56 <brent> PROPOSAL: The v2 context URL will remain normative (https://www.w3.org/ns/credentials/v2), its value will be made normative through the use of a hash digest.
15:52:58 <brent> +1
15:52:59 <dlongley> +1
15:53:01 <mprorock> +1
15:53:02 <andres> +1
15:53:03 <Orie_> +1
15:53:04 <dmitriz> +1
15:53:06 <shigeya> +1
15:53:08 <JoeAndrieu> +1
15:53:09 <decentralgabe> +1
15:53:10 <TallTed> +1
15:53:11 <manu> +1 (and we should add issue markers saying that the value might change before PR and that's expected)
15:53:11 <DavidC> +1
15:53:15 <Will> +1
15:53:31 <ivan_> +1
15:53:31 <ivan_> +1 to manu
15:53:53 <TallTed> +1 w/issue markers
15:53:58 <brent> RESOLVED: The v2 context URL will remain normative (https://www.w3.org/ns/credentials/v2), its value will be made normative through the use of a hash digest.
15:54:33 <mprorock> q+
15:54:41 <brent> ack mprorock
15:55:11 <shigeya> q+
15:55:16 <brent> ack shigeya
15:55:54 <mprorock> shigeya: would versioning change hash - major or minor change?
15:55:57 <brent> PROPOSAL: Add issue markers saying that the value of the hash digest for the v2 context may change before PR and that's expected.
15:56:02 <mprorock> +1
15:56:04 <dlongley> +1
15:56:04 <ivan_> +1
15:56:04 <manu> +1
15:56:05 <Orie_> +1
15:56:06 <DavidC> +1
15:56:06 <andres> +1
15:56:07 <shigeya> +1
15:56:07 <TallTed> +1
15:56:09 <Will> +1
15:56:12 <JoeAndrieu> +1
15:56:12 <brent> +1
15:56:32 <brent> RESOLVED: Add issue markers saying that the value of the hash digest for the v2 context may change before PR and that's expected.
15:56:34 <mprorock> brent: not seeing or hearing objections
15:56:46 <mprorock> brent: thanks everyone for being awesome
15:56:59 <ivan_> rrsagent, draft minutes
15:57:00 <RRSAgent> I have made the request to generate https://www.w3.org/2023/06/13-vcwg-special-minutes.html ivan_
15:57:21 <ivan_> zakim, end meeting
15:57:21 <Zakim> As of this point the attendees have been ivan, TallTed, shigeya, brent, hsano, mprorock, PaulDietrich, andres, smccown, selfissued, kristina, dlongley, manu, WillAbramson, dlehn,
15:57:24 <Zakim> ... Orie_, decentralgabe, dmitriz, DavidC, shawnb
15:57:24 <Zakim> RRSAgent, please draft minutes
15:57:26 <RRSAgent> I have made the request to generate https://www.w3.org/2023/06/13-vcwg-special-minutes.html Zakim
15:57:31 <Zakim> I am happy to have been of service, ivan_; please remember to excuse RRSAgent.  Goodbye
15:57:31 <Zakim> Zakim has left #vcwg-special