18:58:16 RRSAgent has joined #vcwg 18:58:21 logging to https://www.w3.org/2023/08/02-vcwg-irc 18:58:25 zakim, start the meeting 18:58:25 RRSAgent, make logs Public 18:58:27 please title this meeting ("meeting: ..."), brent 18:58:41 meeting: Verifiable Credentials Teleconference 18:58:49 chair: Kristina Yasuda 18:59:16 andres has joined #vcwg 18:59:24 present+ 18:59:29 mprorock has joined #vcwg 18:59:50 present+ mprorock andres 18:59:59 GregB has joined #vcwg 19:00:22 present+ GregB 19:00:28 present+ 19:01:15 kristina has joined #vcwg 19:01:17 present+ 19:01:31 decentralgabe has joined #vcwg 19:01:38 present+ 19:02:28 present+ 19:02:30 scribe+ 19:02:59 present+ 19:03:17 DavidC has joined #vcwg 19:03:23 present+ 19:03:47 kristina: Welcome everyone, agenda is PRs and issues, we did good job on PRs yesterday, so we are skipping PRs today. 19:04:21 kristina: I did merge ecosystem PR, 13-16 approvals, which was good, merged, other PRs could get merged as a result of discussion yesterday. 19:04:22 present+ 19:04:30 q+ 19:04:42 q+ 19:04:55 ack manu 19:05:04 kristina: Any PRs we should discuss? 19:05:05 ack mprorock 19:05:24 Topic: PRs 19:05:27 manu: Not really, just look at PRs out there... ecdsa-sd is going to be merged this week... MikeP has other PRs he might want to cover. 19:05:48 mprorock: PR69 -- did get some text pushed today that adjusted top-level typing to BitStringStatusList, please put eyes on that... 19:06:04 https://github.com/w3c/vc-jose-cose/pull/88/files#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051L403-L426 19:06:17 zakim, who is here? 19:06:17 Present: brent, mprorock, andres, GregB, kristina, decentralgabe, manu, seabass, DavidC 19:06:20 On IRC I see DavidC, decentralgabe, kristina, GregB, mprorock, andres, RRSAgent, Zakim, brent, dmitriz, tzviya, manu, csarven, bumblefudge1, cel[m], w3c_modbot, ounfacdo, seabass, 19:06:20 ... saysaywhat, npd, MojGraph, cel[h], bumblefudge, Github, dlehn, shigeya, bigbluehat, Dongwoo, hadleybeeman, stonematt, stenr, cel, dlongley, rhiaro 19:06:38 present+ 19:06:41 mprorock: The other one is PR88, in VC-JOSE-COSE, blocker at this point -- fixing one last thing -- that will have approval from Orie/myself as Editors -- that is blocking on additional work. 19:06:57 mprorock: This removes stuff in v1.1, not addressed by this specification. 19:06:59 q? 19:07:18 kristina: Do we need special topic call on status list PR? 19:07:24 Orie has joined #vcwg 19:07:28 mprorock: only mikej is blocking that one. 19:07:35 Present+ 19:07:48 mprorock: We'd like chairs to identify consensus on this to be unblocked on PR 88... 19:08:06 mprorock: VC-COSE-JOSE is blocked. 19:08:14 mprorock: Status List is just going through normal review/ bikeshedding. 19:08:14 present+ kgriffin 19:08:59 q? 19:09:01 kristina: do we need special topic call for either one of these? 19:09:04 mprorock: No, I don't thikn so 19:09:11 s/thikn/think/ 19:09:25 ack seabass 19:09:34 Topic: Issues 19:09:37 q+ 19:09:37 q+ 19:09:47 seabass: Why are CBOR / JSON parts part of same specification instead of being a part of different specifications? 19:09:47 q- 19:09:47 ack Orie 19:09:53 ack mprorock 19:10:33 Orie: The core data model provides content types for conforming documents, for JOSE/COSE, there is a way to secure content types as per in core data model... why would you want to use COSE instead of JOSE? You might want to use COSE QR Codes, other aspects of CBOR system, because core data model is JSON-LD, you have to embed content type that you're securing. 19:11:07 Orie: Because you secure stuff in the same way in JOSE / COSE, and you do key discovery the same way -- that's why we put them together, to make sure same approach is used for both JOSE and COSE. 19:11:12 topic: issues 19:11:36 kristina: Brent, should we do any label for issues today? 19:12:00 brent: Let's try in least-recently-updated order. 19:12:10 https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+-label%3Abefore-CR+-label%3A%22pending+close%22+sort%3Aupdated-asc+ 19:12:35 kristina: There's the link, we're going through "before CR" issues. 19:12:41 kgriffin has joined #vcwg 19:12:43 https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3Abefore-CR+sort%3Aupdated-asc+ 19:13:16 subtopic: https://github.com/w3c/vc-data-model/issues/959 19:13:31 several PRs are open regarding "holder" 19:13:48 We are discussing https://github.com/w3c/vc-data-model/issues/959 19:14:08 people asked in its related to https://github.com/w3c/vc-data-model/pull/1199 ... it is. 19:14:21 kristina: where are we on this issue? 19:14:42 q? 19:14:44 kristina: Does 1199 directly address this issue? 19:15:13 Orie: Brent clarified some of this in another PR, PR1199 also clarifies parts of this, I don't know if it's sufficient to close the issue... let's try to close this issue if PR 1199 does address this issue. 19:15:34 kristina: Ok, makes sense, marked as pr exists. 19:15:46 kristina: direction is to close issue when PR 1199 is merged. 19:16:03 subtopic: https://github.com/w3c/vc-data-model/issues/1177 19:16:07 subtopic: https://github.com/w3c/vc-data-model/issues/1177 19:16:17 kristina: manu, status? 19:16:23 manu: I will do this PR, straighforward PR. 19:16:28 JoeAndrieu has joined #vcwg 19:16:33 q+ 19:16:36 subtopic: https://github.com/w3c/vc-data-model/issues/991 19:16:58 ack brent 19:17:21 brent: if we want for ready for PR, ask assigned person what their timeline could be -- that might be valuable quesiton to ask. 19:17:47 q+ 19:17:54 ack DavidC 19:17:56 kristina: for clarify credentialStatus --- DavidC go ahead. 19:18:43 q+ to say verifiable credential are not secured... 19:18:46 does that object /need/ a name? 19:19:10 DavidC: This is partly tied into the difference between credential and verifible credential... manu tried to clarify that text... the definition of verifiable credential is that it's secured... what is the object called that is unsecured. That hasn't been answered satisfactorily... the text for this one, underlying object or credential could be revoked, vc could be revoked.... we haven't fully nailed down what we call the unsecured verifiable credential. 19:19:25 DavidC: I don't believe it can be called credential... VC and C seemed to be same object before. 19:19:33 q+ seabass 19:19:34 q+ 19:19:45 ack Orie 19:19:45 Orie, you wanted to say verifiable credential are not secured... 19:20:33 Orie: I agree with some of what David Chadwick said, we're still struggling Credential vs. VC language -- manu has PR w/ languaeg speaking to it... the way I'm making sense of this is specification registers two media types, subtypes of JSON, and they might be secured or they might not be and up to verifier to check... media types are hints, not assurance that somethng has security. 19:20:58 +1 orie 19:21:00 ack seabass 19:21:03 Orie: vc+ld+json is JSON media type of something that might not be secured... just be careful about how interpret this. 19:21:37 seabass: Three different scenarios, VC (valid in terms of structure and secure in it has a cryptographic proof), but receiver has not yet done either verification of structure nor have they done cryptography to ensure signature is correct. That is a "pending VC". 19:21:50 q+ to say I don't think we have anything to say about credentials other than VCs 19:21:52 seabass: Another is thatyou have a VC that was once valid, but has been revoked, and one could call that "revoked VC" 19:22:16 seabass: Final scenario is where everything is fine, "verified VC" -- if we can find a new name for that, confusion might remain. 19:22:17 ack manu 19:22:18 q+ 19:22:24 scribe+ 19:23:15 `proof` is optional... so that seems to conflict with the RDF type definition. 19:23:31 +1 to @manu that a VC is always secured 19:23:45 manu: There is a PR out to fix the issue. It says that a Verifiable Credential credential is secured. PR means that it has to be secured for you to call it a VC. That does not preclude it from having errors. 19:24:13 its a mistake to use english language that contradicts the RDF data model. 19:24:22 to reconcile with orie's interpretation of vc+ld+json, vcdm does not say where to use that media type so it can be cty in vc-jose-cose, so should be no conflict..? 19:24:24 manu: One school of thought is that it doesn't matter, another school of thought is that invalid or erroneous data can not be called a Verifiable Credential. 19:24:46 +1 to @manu that vc and c are not the same thing 19:25:00 manu: The current PR tries to say that it conforms to our document, and it is secure. A 'credential document' is the term for things that aren't secure or aren't conforment. 19:25:03 PR Manu is talking about: https://github.com/w3c/vc-data-model/pull/1211 19:25:18 q? 19:25:22 ack JoeAndrieu 19:25:22 JoeAndrieu, you wanted to say I don't think we have anything to say about credentials other than VCs 19:25:53 q+ 19:25:59 JoeAndrieu: I preferred the other language, felt like there were two dimensions, other dimensionality -- difference between VC and credential in real world... having a bachelors degree, have that whether or not I have a VC... but that's not what this is about. 19:26:14 JoeAndrieu: When we sign a credential, not sure how to coherently describe position, will try again later. 19:26:35 ack DavidC 19:26:38 kristina: PR1211 might address this, anything else that needs to be done. 19:26:55 DavidC: Yes, this is good, glad you changed position manu, that aligns w/ what I was concerned w/ all along... you and I agree now. 19:27:18 cabernet has joined #vcwg 19:27:22 present+ 19:27:26 DavidC: The PR that we are discussing now, what is underlying document/credential/cerificatte -- we start w/ paper document, that is turned into some JSON (credential), which is then turned into (verifiable credential) w/ proof on it. 19:27:44 q+ to say "credential object" 19:27:45 DavidC: This PR was talking about first and 3rd object... how do we signal that... agreeing that we are not going to say anything about underlying paper document 19:27:49 q+ to agree w/ DavidC 19:28:14 DavidC: That is what this PR was about... your degree is removed, but VC is still around saying you had a degree. That's what we're trying to address in terms of revocation. 19:28:39 kristina: can you add language to clarify this, Manu? 19:28:42 ack seabass 19:28:42 manu: I will try my best. 19:29:06 seabass: Respoding to DavidC -- if there is consensus one way or another, we hsould have resolution that we are are/not addressing first layer in VCs. 19:29:15 seabass: Looking for input on that. 19:29:39 no 19:29:41 seabass: before something becomes JSON -- paper credential -- are we talking about that? if physical degree is revoked, is VC-native way that addresses that situation? 19:30:03 DavidC: Yes, that's what this issue was about? 19:30:13 seabass: Yes, would like to see resolution -- 19:30:14 ack JoeAndrieu 19:30:14 JoeAndrieu, you wanted to say "credential object" 19:30:47 JoeAndrieu: With a slight refactoring, we already do that -- we don't have mechanism to separate revocation of real world paper credential from digital version... we do have a mechanism to state that VC is revoked. 19:30:58 q+ 19:31:00 The revocation check of the real world credential sounds entirely out of scope for our group 19:31:04 JoeAndrieu: You said "Credential Object", made sense to me DavidC, JSON that's not signed yet. 19:32:06 there are two things: validity of the signature and validity of the data about the subject. we have status list for the latter and individual mechanism per securing mechanism 19:32:15 I am pretty confused what we need beyond that 19:32:38 seabass: For status list, which allows revocation for VC... difference between that and real world credential... if you revoke VC, because you gave no reason for that, cryptography for revoking, don't know if that credential was ever valid... maintaining list of changes, knowledge graph, can you say "I once believed that the person had a degree" -- important aspect. 19:32:48 status list isn't for cryptographic revocation 19:32:51 ack manu 19:32:51 manu, you wanted to agree w/ DavidC 19:32:55 scribe+ 19:33:00 q- DavidC 19:33:46 manu: I really like David Chadwick's model of three parts. I see that Orie's concern that the language and the RDF definitions don't match, for which I have some PRs to resolve the difference. 19:34:04 manu: The thing we care most about in this specification is the third and final part, which has to be secured. 19:34:21 q+ 19:34:45 manu: We can add a new RDF term to align with this new three-part model. 19:34:54 kristina: I think manu has enough data to update the PR. 19:35:08 ack Orie 19:35:26 q? 19:35:46 Orie: We did start w/ abstract credential class -- that VC inherited from -- all of this happened before, it'll all happen again. 19:36:20 kristina: ETA for hashes PR, manu? 19:36:23 manu: Within two weeks. 19:36:34 subtopic: https://github.com/w3c/vc-data-model/issues/1153 19:37:22 mprorock: How do we test this? We could check if hash matches, build into VCDM tests -- fairly straight forward. 19:37:22 q+ 19:37:28 kristina: Are you volunteering to do the PR? 19:37:37 ack Orie 19:37:38 mprorock: I can provide sample code for this, could go into PR, or whatever. 19:37:55 we did 19:38:04 Orie: I might be misremembering, thought we added property for protecting context integrity, if securing specification wanted to demonstrate conformance, it would have to write tests around it. 19:38:33 Orie: Manu sent email about data integrity suites -- would expect to see some test case there for this, would also epect to see stuff for VC-COSE-JOSE test suite and would love to see that adopted. 19:38:34 +1 orie - and I am happy to add to vc-jose tests 19:38:43 Orie: We dont' have adopted work items for test suites in group. 19:38:52 q+ 19:38:52 kristina: Moving issue to VC-JOSE-COSE repo? 19:38:56 ack Orie 19:39:26 Orie: This particular core data model issue is fine to stay on core data model -- it will need to be tested concretely in test suites for securing core data model, those tests suites will use different approaches, I'd leave it where it is. 19:39:35 Orie: I'd file issues in test suites repos, if we had those. 19:39:36 q? 19:40:01 subtopic: https://github.com/w3c/vc-data-model/issues/1047 19:40:46 +1 to talking about test suites 19:41:07 kristina: Manu sent out of an email about test suite adoption, we'll discuss that in an upcoming call. 19:41:18 q? 19:41:27 q+ 19:41:32 ack Orie 19:42:26 Orie: I think the core data model has terminology, and sometimes it aligns strongly w/ existing definition, and sometimes it doesn't... Data Integrity specs had NIST relationships with them, we should be cautious to refer to NIST w/o referring to their terminology... NIST has conflicting definitions for these things... looking at you "attestation" -- highly problematic. 19:42:45 also https://www.rfc-editor.org/rfc/rfc4949.html 19:43:10 q? 19:43:10 Orie: To resolve this, we either go through our terms and add references to other sources so you can navigate them, or to create informative part wrt. disambiguation and do that outside of term list so our term list can stay clean, small, instead of us trying to rationalize how others have defined their terminology. 19:43:16 q+ 19:43:17 kgriffin-again has joined #vcwg 19:43:21 ack mprorock 19:43:28 kristina: other ways to do this? 19:44:28 mprorock: RFC4949 defines some of this stuff -- they cite a bunch of other definitions because there are multiple definitions... would like to point to work/reviewed published -- or creating definition of term that is confusing to those trrying to integrate w/ our stuff... 19:44:56 mprorock: seen a lot of cases of this, NIST draft going out -- spent hours w/ NIST as did others trying to cross-reference others -- really problematic. 19:45:02 q+ 19:45:15 kristina: We have Charles assigned... should we add Orie? 19:45:16 ack seabass 19:45:17 you can assign ment 19:45:35 s/ment/me/ 19:45:55 done :) 19:46:00 seabass: I don't want to negate effort of those compiling glossaries in the past, don't think average is going to look at our use of "credential" and say "my implementation isn't accurate"... it might be useful from a marketing perspective, but probably won't affect implementability of VCs. 19:46:03 +1 19:46:10 manu: +1 to seabass 19:47:03 subtopic: https://github.com/w3c/vc-data-model/issues/1185 19:47:41 kristina: what should conformance processor expect regarding normative requirements for context. 19:48:12 q+ 19:48:25 ack manu 19:48:35 scribe+ 19:48:59 manu: What would Orie like the specification to say? 19:49:07 q+ 19:49:25 ack Orie 19:49:29 manu: We have this JSON-processing part of the specification, whereas this is specifically about JSON-LD features of JSON. 19:49:57 +1 orie 19:50:16 orie: We should describe that, when processing VCs as JSON-LD rather than plain JSON, you must use the context in a particular way. 19:50:19 Orie: Yes, that's basically it. We have this section now that says you can process core data model as JSON -- with context being normative, we should also describe "if you process as JSON-LD, this is why we made context normative, so you get other values expected" -- any application that uses @context would prove value of making @context normative. 19:50:47 q? 19:50:50 Orie: Issuers/verifiers/holders why do they need same underlying value? It's what enables these other capabilities... if you go beyond traditional JSON, what should you get, we should make that clear to readers. 19:50:50 q+ 19:50:54 ack manu 19:51:19 q+ 19:51:25 don't make json processing PR bigger 19:51:29 please :) 19:51:58 https://github.com/w3c/vc-data-model/pull/1202#discussion_r1273762313 19:52:09 q+ 19:52:11 ack mprorock 19:52:31 scribe+ manu 19:52:51 mprorock: Comment made on JSON Processing PR -- maybe we should add corresponding section on JSON-LD... I think we should, I think that's what manu is saying, that's what Orie is saying... we're beating the "JSON Processing PR" to death... let's get a corresponding PR for JSON-LD Processing as well. 19:52:53 ack kristina 19:53:23 q+ 19:53:32 ack Orie 19:53:35 kristina: Yes, separate PRs are fine, but it would be great if -- woul dlike to see second PR in parallel to JSON Processing PR -- my concern was ... what's value of @context if pure JSON processing is possible, if that goes in, that addresses part of my concern... understand they don't have to go in same PR. 19:54:54 Orie: I agree with point on confusion, it is confusing to just have JSON Processing, but also have acknowledgement of @context values are normative... I udnerstand why it is that way, I think that language is correct, but I think other people will be confused until they see these things side-by-side, and that's caused JSON Processing to take longer. I would prefer JSON Processing to go in, keeping both of them open, will make review really hard -- I 19:54:54 would recommend merging JSON Processing PR -- then filing bunch of issues to come up /align from review process -- easier to reduce parallel places we're having conversations. 19:54:56 q? 19:55:13 manu: +1 to what Orie and mikeP just said. 19:55:21 +1 to Orie 19:55:39 kristina: Ok, marking this as ready for PR. 19:55:52 kristina: agree that both have to happen 19:56:14 kristina: next week is going to be discussion on test suite special topic call... main call will be issue processing. 19:56:20 kristina: Thanks all, see you next week. 19:56:29 rrsagent, draft minutes. 19:56:29 I'm logging. I don't understand 'draft minutes.', manu. Try /msg RRSAgent help 19:56:34 rrsagent, draft minutes 19:56:35 I have made the request to generate https://www.w3.org/2023/08/02-vcwg-minutes.html manu 19:57:21 zakim, end the meeting 19:57:21 As of this point the attendees have been brent, mprorock, andres, GregB, kristina, decentralgabe, manu, seabass, DavidC, dmitriz, Orie, kgriffin, cabernet 19:57:24 RRSAgent, please draft minutes 19:57:25 I have made the request to generate https://www.w3.org/2023/08/02-vcwg-minutes.html Zakim 19:57:30 I am happy to have been of service, brent; please remember to excuse RRSAgent. Goodbye 19:57:30 Zakim has left #vcwg 19:57:35 rrsagent, bye 19:57:35 I see no action items