18:58:16 <RRSAgent> RRSAgent has joined #vcwg
18:58:21 <RRSAgent> logging to https://www.w3.org/2023/08/02-vcwg-irc
18:58:25 <brent> zakim, start the meeting
18:58:25 <Zakim> RRSAgent, make logs Public
18:58:27 <Zakim> please title this meeting ("meeting: ..."), brent
18:58:41 <brent> meeting: Verifiable Credentials Teleconference
18:58:49 <brent> chair: Kristina Yasuda
18:59:16 <andres> andres has joined #vcwg
18:59:24 <brent> present+
18:59:29 <mprorock> mprorock has joined #vcwg
18:59:50 <brent> present+ mprorock andres
18:59:59 <GregB> GregB has joined #vcwg
19:00:22 <brent> present+ GregB
19:00:28 <GregB> present+
19:01:15 <kristina> kristina has joined #vcwg
19:01:17 <kristina> present+
19:01:31 <decentralgabe> decentralgabe has joined #vcwg
19:01:38 <decentralgabe> present+
19:02:28 <manu> present+
19:02:30 <manu> scribe+
19:02:59 <seabass> present+
19:03:17 <DavidC> DavidC has joined #vcwg
19:03:23 <DavidC> present+
19:03:47 <manu> kristina: Welcome everyone, agenda is PRs and issues, we did good job on PRs yesterday, so we are skipping PRs today.
19:04:21 <manu> 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 <andres> present+
19:04:30 <manu> q+
19:04:42 <mprorock> q+
19:04:55 <kristina> ack manu
19:05:04 <manu> kristina: Any PRs we should discuss?
19:05:05 <kristina> ack mprorock
19:05:24 <brent> Topic: PRs
19:05:27 <manu> 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 <manu> mprorock: PR69 -- did get some text pushed today that adjusted top-level typing to BitStringStatusList, please put eyes on that...
19:06:04 <mprorock> https://github.com/w3c/vc-jose-cose/pull/88/files#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051L403-L426
19:06:17 <brent> zakim, who is here?
19:06:17 <Zakim> Present: brent, mprorock, andres, GregB, kristina, decentralgabe, manu, seabass, DavidC
19:06:20 <Zakim> 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 <Zakim> ... saysaywhat, npd, MojGraph, cel[h], bumblefudge, Github, dlehn, shigeya, bigbluehat, Dongwoo, hadleybeeman, stonematt, stenr, cel, dlongley, rhiaro
19:06:38 <dmitriz> present+
19:06:41 <manu> 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 <manu> mprorock: This removes stuff in v1.1, not addressed by this specification.
19:06:59 <kristina> q?
19:07:18 <manu> kristina: Do we need special topic call on status list PR?
19:07:24 <Orie> Orie has joined #vcwg
19:07:28 <manu> mprorock: only mikej is blocking that one.
19:07:35 <Orie> Present+
19:07:48 <manu> mprorock: We'd like chairs to identify consensus on this to be unblocked on PR 88...
19:08:06 <manu> mprorock: VC-COSE-JOSE is blocked.
19:08:14 <manu> mprorock: Status List is just going through normal review/ bikeshedding.
19:08:14 <brent> present+ kgriffin
19:08:59 <kristina> q?
19:09:01 <manu> kristina: do we need special topic call for either one of these?
19:09:04 <manu> mprorock: No, I don't thikn so
19:09:11 <manu> s/thikn/think/
19:09:25 <kristina> ack seabass
19:09:34 <brent> Topic: Issues
19:09:37 <mprorock> q+
19:09:37 <Orie> q+
19:09:47 <manu> seabass: Why are CBOR / JSON parts part of same specification instead of being a part of different specifications?
19:09:47 <mprorock> q-
19:09:47 <kristina> ack Orie
19:09:53 <kristina> ack mprorock
19:10:33 <manu> 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 <manu> 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 <kristina> topic: issues
19:11:36 <manu> kristina: Brent, should we do any label for issues today?
19:12:00 <manu> brent: Let's try in least-recently-updated order.
19:12:10 <kristina> 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 <manu> kristina: There's the link, we're going through "before CR" issues.
19:12:41 <kgriffin> kgriffin has joined #vcwg
19:12:43 <kristina> https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3Abefore-CR+sort%3Aupdated-asc+
19:13:16 <manu> subtopic: https://github.com/w3c/vc-data-model/issues/959
19:13:31 <Orie> several PRs are open regarding "holder"
19:13:48 <Orie> We are discussing https://github.com/w3c/vc-data-model/issues/959
19:14:08 <Orie> people asked in its related to https://github.com/w3c/vc-data-model/pull/1199 ... it is.
19:14:21 <manu> kristina: where are we on this issue?
19:14:42 <kristina> q?
19:14:44 <manu> kristina: Does 1199 directly address this issue?
19:15:13 <manu> 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 <manu> kristina: Ok, makes sense, marked as pr exists.
19:15:46 <manu> kristina: direction is to close issue when PR 1199 is merged.
19:16:03 <manu> subtopic: https://github.com/w3c/vc-data-model/issues/1177
19:16:07 <kristina> subtopic: https://github.com/w3c/vc-data-model/issues/1177
19:16:17 <manu> kristina: manu, status?
19:16:23 <manu> manu: I will do this PR, straighforward PR.
19:16:28 <JoeAndrieu> JoeAndrieu has joined #vcwg
19:16:33 <brent> q+
19:16:36 <kristina> subtopic: https://github.com/w3c/vc-data-model/issues/991
19:16:58 <kristina> ack brent
19:17:21 <manu> 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 <DavidC> q+
19:17:54 <kristina> ack DavidC
19:17:56 <manu> kristina: for clarify credentialStatus --- DavidC go ahead.
19:18:43 <Orie> q+ to say verifiable credential are not secured...
19:18:46 <dmitriz> does that object /need/ a name?
19:19:10 <manu> 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 <manu> DavidC: I don't believe it can be called credential... VC and C seemed to be same object before.
19:19:33 <manu> q+ seabass
19:19:34 <manu> q+
19:19:45 <kristina> ack Orie
19:19:45 <Zakim> Orie, you wanted to say verifiable credential are not secured...
19:20:33 <manu> 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 <mprorock> +1 orie
19:21:00 <kristina> ack seabass
19:21:03 <manu> 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 <manu> 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 <JoeAndrieu> q+ to say I don't think we have anything to say about credentials other than VCs
19:21:52 <manu> 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 <manu> 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 <kristina> ack manu
19:22:18 <DavidC> q+
19:22:24 <seabass> scribe+
19:23:15 <Orie> `proof` is optional... so that seems to conflict with the RDF type definition.
19:23:31 <DavidC> +1 to @manu that a VC is always secured
19:23:45 <seabass> 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 <Orie> its a mistake to use english language that contradicts the RDF data model.
19:24:22 <kristina> 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 <seabass> 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 <DavidC> +1 to @manu that vc and c are not the same thing
19:25:00 <seabass> 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 <brent> PR Manu is talking about: https://github.com/w3c/vc-data-model/pull/1211
19:25:18 <kristina> q?
19:25:22 <kristina> ack JoeAndrieu
19:25:22 <Zakim> JoeAndrieu, you wanted to say I don't think we have anything to say about credentials other than VCs
19:25:53 <seabass> q+
19:25:59 <manu> 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 <manu> JoeAndrieu: When we sign a credential, not sure how to coherently describe position, will try again later.
19:26:35 <kristina> ack DavidC
19:26:38 <manu> kristina: PR1211 might address this, anything else that needs to be done.
19:26:55 <manu> 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> cabernet has joined #vcwg
19:27:22 <cabernet> present+
19:27:26 <manu> 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 <JoeAndrieu> q+ to say "credential object"
19:27:45 <manu> 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 <manu> q+ to agree w/ DavidC
19:28:14 <manu> 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 <manu> kristina: can you add language to clarify this, Manu?
19:28:42 <kristina> ack seabass
19:28:42 <manu> manu: I will try my best.
19:29:06 <manu> 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 <manu> seabass: Looking for input on that.
19:29:39 <mprorock> no
19:29:41 <manu> 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 <manu> DavidC: Yes, that's what this issue was about?
19:30:13 <manu> seabass: Yes, would like to see resolution --
19:30:14 <kristina> ack JoeAndrieu
19:30:14 <Zakim> JoeAndrieu, you wanted to say "credential object"
19:30:47 <manu> 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 <DavidC> q+
19:31:00 <brent> The revocation check of the real world credential sounds entirely out of scope for our group
19:31:04 <manu> JoeAndrieu: You said "Credential Object", made sense to me DavidC, JSON that's not signed yet.
19:32:06 <kristina> 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 <kristina> I am pretty confused what we need beyond that
19:32:38 <manu> 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 <JoeAndrieu> status list isn't for cryptographic revocation
19:32:51 <kristina> ack manu
19:32:51 <Zakim> manu, you wanted to agree w/ DavidC
19:32:55 <seabass> scribe+
19:33:00 <kristina> q- DavidC
19:33:46 <seabass> 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 <seabass> manu: The thing we care most about in this specification is the third and final part, which has to be secured.
19:34:21 <Orie> q+
19:34:45 <seabass> manu: We can add a new RDF term to align with this new three-part model.
19:34:54 <manu> kristina: I think manu has enough data to update the PR.
19:35:08 <kristina> ack Orie
19:35:26 <dmitriz> q?
19:35:46 <manu> 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 <manu> kristina: ETA for hashes PR, manu?
19:36:23 <manu> manu: Within two weeks.
19:36:34 <kristina> subtopic: https://github.com/w3c/vc-data-model/issues/1153
19:37:22 <manu> mprorock: How do we test this? We could check if hash matches, build into VCDM tests -- fairly straight forward.
19:37:22 <Orie> q+
19:37:28 <manu> kristina: Are you volunteering to do the PR?
19:37:37 <kristina> ack Orie
19:37:38 <manu> mprorock: I can provide sample code for this, could go into PR, or whatever.
19:37:55 <mprorock> we did
19:38:04 <manu> 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 <manu> 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 <mprorock> +1 orie - and I am happy to add to vc-jose tests
19:38:43 <manu> Orie: We dont' have adopted work items for test suites in group.
19:38:52 <Orie> q+
19:38:52 <manu> kristina: Moving issue to VC-JOSE-COSE repo?
19:38:56 <kristina> ack Orie
19:39:26 <manu> 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 <manu> Orie: I'd file issues in test suites repos, if we had those.
19:39:36 <kristina> q?
19:40:01 <kristina> subtopic: https://github.com/w3c/vc-data-model/issues/1047
19:40:46 <Orie> +1 to talking about test suites
19:41:07 <manu> kristina: Manu sent out of an email about test suite adoption, we'll discuss that in an upcoming call.
19:41:18 <kristina> q?
19:41:27 <Orie> q+
19:41:32 <kristina> ack Orie
19:42:26 <manu> 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 <mprorock> also https://www.rfc-editor.org/rfc/rfc4949.html
19:43:10 <kristina> q?
19:43:10 <manu> 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 <mprorock> q+
19:43:17 <kgriffin-again> kgriffin-again has joined #vcwg
19:43:21 <kristina> ack mprorock
19:43:28 <manu> kristina: other ways to do this?
19:44:28 <manu> 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 <manu> 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 <seabass> q+
19:45:15 <manu> kristina: We have Charles assigned... should we add Orie?
19:45:16 <kristina> ack seabass
19:45:17 <Orie> you can assign ment
19:45:35 <Orie> s/ment/me/
19:45:55 <kristina> done :)
19:46:00 <manu> 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 <brent> +1
19:46:10 <manu> manu: +1 to seabass
19:47:03 <kristina> subtopic: https://github.com/w3c/vc-data-model/issues/1185
19:47:41 <manu> kristina: what should conformance processor expect regarding normative requirements for context.
19:48:12 <manu> q+
19:48:25 <kristina> ack manu
19:48:35 <seabass> scribe+
19:48:59 <seabass> manu: What would Orie like the specification to say?
19:49:07 <Orie> q+
19:49:25 <kristina> ack Orie
19:49:29 <seabass> manu: We have this JSON-processing part of the specification, whereas this is specifically about JSON-LD features of JSON.
19:49:57 <mprorock> +1 orie
19:50:16 <seabass> 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 <manu> 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 <kristina> q?
19:50:50 <manu> 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 <manu> q+
19:50:54 <kristina> ack manu
19:51:19 <mprorock> q+
19:51:25 <Orie> don't make json processing PR bigger
19:51:29 <Orie> please :)
19:51:58 <mprorock> https://github.com/w3c/vc-data-model/pull/1202#discussion_r1273762313
19:52:09 <kristina> q+
19:52:11 <kristina> ack mprorock
19:52:31 <seabass> scribe+ manu
19:52:51 <manu> 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 <kristina> ack kristina
19:53:23 <Orie> q+
19:53:32 <kristina> ack Orie
19:53:35 <manu> 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 <manu> 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 <manu> 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 <kristina> q?
19:55:13 <manu> manu: +1 to what Orie and mikeP just said.
19:55:21 <brent> +1 to Orie
19:55:39 <manu> kristina: Ok, marking this as ready for PR.
19:55:52 <manu> kristina: agree that both have to happen
19:56:14 <manu> kristina: next week is going to be discussion on test suite special topic call... main call will be issue processing.
19:56:20 <manu> kristina: Thanks all, see you next week.
19:56:29 <manu> rrsagent, draft minutes.
19:56:29 <RRSAgent> I'm logging. I don't understand 'draft minutes.', manu.  Try /msg RRSAgent help
19:56:34 <manu> rrsagent, draft minutes
19:56:35 <RRSAgent> I have made the request to generate https://www.w3.org/2023/08/02-vcwg-minutes.html manu
19:57:21 <brent> zakim, end the meeting
19:57:21 <Zakim> As of this point the attendees have been brent, mprorock, andres, GregB, kristina, decentralgabe, manu, seabass, DavidC, dmitriz, Orie, kgriffin, cabernet
19:57:24 <Zakim> RRSAgent, please draft minutes
19:57:25 <RRSAgent> I have made the request to generate https://www.w3.org/2023/08/02-vcwg-minutes.html Zakim
19:57:30 <Zakim> I am happy to have been of service, brent; please remember to excuse RRSAgent.  Goodbye
19:57:30 <Zakim> Zakim has left #vcwg
19:57:35 <brent> rrsagent, bye
19:57:35 <RRSAgent> I see no action items