21:43:11 RRSAgent has joined #vcwg-special 21:43:15 logging to https://www.w3.org/2023/06/20-vcwg-special-irc 21:44:31 brent has changed the topic to: Meeting Agenda 2023-06-20: https://www.w3.org/events/meetings/eaf86734-c2f9-410e-86b9-1cca18d0d6c9/20230620T180000/ 21:58:19 pl-ASU has joined #vcwg-special 21:59:11 zakim, start the meeting 21:59:11 RRSAgent, make logs Public 21:59:13 please title this meeting ("meeting: ..."), brent 21:59:27 meeting: Verifiable Credentials Working Group Special Topic Call 21:59:29 mprorock has joined #vcwg-special 21:59:32 chair: Brent Zundel 21:59:35 present" 21:59:39 present+ 22:00:15 present+ 22:00:18 decentralgabe has joined #vcwg-special 22:00:22 present+ 22:00:51 JoeAndrieu_ has joined #vcwg-special 22:02:23 brentz has joined #vcwg-special 22:04:45 scribe+ 22:05:02 presence+ 22:05:04 present+ 22:05:05 present+ 22:05:10 present+ 22:05:23 brent: agenda today is pr #65 in the vc-status-list repo 22:05:24 subtopic: https://github.com/w3c/vc-status-list-2021/pull/65 22:06:04 ... plan today is to (1) time to mprorock for goals/what he hopes to accomplish. (2) if we can come to consensus and merge lets do that 22:06:47 mprorock: walking through the PR. there is a common case. rather than only a boolean option for a status and its type by status purpose, ability for one of multiple statuses 22:07:02 selfissued has joined #vcwg-special 22:07:07 present+ 22:07:14 hsano has joined #vcwg-special 22:07:25 present+ 22:07:30 ...IoT case: may have system status from a set. with VCs desire need to attach one or more of those statuses. this PR addresses that need. 22:07:52 ... questions: what if I want multiple statuses? that is beyond the scope of this PR which is just focused on choosing one status out of many 22:08:25 smccown has joined #vcwg-special 22:09:30 ... status codes are well known up front and don't change often. having a change is worth having a new credential itself. in order to have this work with existing status purpose we need a new status purpose to indicate there's a status message attached. indicate how many bits are associated with the status code. based on that size able to represent status (e.g. boolean would be 1 bit) 22:10:08 ... could be more than 1 bit. let you do lookup tables. e.g. get status position 3, multiple size by 3, unpack bitstring...low lift for impls. just need to see if there's a size reflected, then can have >1 status code 22:10:55 ... dlongley brought up a good point--we may want to make sure verifiers of a credential know if there's a verification step associated with the cred. is it informational, or does it impact the credential's validity? 22:11:22 ... need to communicate to a verifier whether they should look for a certain status code, could be confusion here. 22:11:58 .. strawman open proposal: should we have a status purpose that indicates it's informational, and a purpose that indicates it has verification information as well 22:13:04 ... manu has raised concerns around privacy. should be follow-on PRs to address. e.g. customs, cross border traffic, already you are correlating a lot. may not be appropriate to take this until its well understood and applied to many use cases. want to make sure theres no correlation, or very little. if we could get language on this call happy to add it, or a subsequent PR 22:13:06 q? 22:13:09 q+ 22:13:27 ... in the PR line 621 in the files that's where the examples start. makes sense to start there 22:13:30 q+ to agree that this is a legitimate use case, suggest some other ways to structure the feature. 22:13:41 ack TallTed 22:13:43 brentz: looking for concrete proposals to move this forward 22:13:59 TallTed: suggest Mike go through and approve/reject changes made; will be easier to review after 22:14:18 mprorock: were some conflicts so I didn't yet, let's see if we can hash it out here so I can approve/deny appropriately 22:14:34 TallTed: comment on those you see that in, mostly just fixing typos 22:14:42 mprorock: will take a look 22:14:45 ack manu 22:14:45 manu, you wanted to agree that this is a legitimate use case, suggest some other ways to structure the feature. 22:15:45 manu: agree this is a legitimate use case. for a shipment, want to accept multiple messages associated with it. number of concerns highlighted with the PR...but to be clear we should figure out a way to address this use case. could potentially be addressed in the way proposed now, but concerned it's conflating two things we won't want to conflate 22:16:24 ... first - binary bit field. in current incarnation sets to create a privacy preserving mechanism to communicate binary status. expanding into multiple messages changes privacy characteristics of the mechanism. now have more bits to correlate the data. 22:16:49 q+ 22:16:59 ... maybe could address in the security considerations, but I am concerned with that. it is about messages-- want to convey a series of messages about a subject, a credential, which is significantly different than what we were doing before 22:17:06 q+ to suggest maybe a secondary endpoint for details and a single boolean for "we still stand by this VC" 22:18:11 ... has been an attempt to address that with adding a verify flag with every message. concern there is that this new message mechanism is suggested to be optional. if you don't implement it, what is the default supposed to be? if not verify, and you don't verify...could result in a failure to verify which is not a desirable outcome 22:18:54 ... wondering if we can split the feature into two. make the spec about conveying status info as is, simple boolean. create another thing in the spec which talks about status messages, which keep all the qualities in the PR, but with a clean separation between the two in the spec. can use the same algs 22:19:34 ... try to split it into a different type of thing, where you can have much stronger statements about impl the normative statements about that thing. right now both features are stomping on each other. cleaner to separate 22:19:36 +1 to keeping on specification simple, and another that is designed for message complexity. 22:19:43 q? 22:19:47 ack mprorock 22:20:28 mprorock: suggest, if that's the case, that revocation and suspension are misnamed and are verification lists not status lists. the status purpose does provide that clean separation. if we want to change 'status' to 'informational status message' or other, that's a fine way to break that separation 22:21:02 ... suggest status and status-message or status-verification. if verify/verification/whatever is in the status purpose then it indicates there's verification info in the status 22:21:56 q+ to reiterate the problem w/ different types of status lists being expressed w/ the same type. 22:22:01 ... there are cases, like Kristina commented, where 0 bit = fine, 1 = revoked, 2 = suspended, etc and there's a flag carried along. might be a little messy. want as good separation as we can. if status purpose is not 'what is the purpose of this status attached' not sure what it is for 22:22:02 ack JoeAndrieu_ 22:22:02 JoeAndrieu_, you wanted to suggest maybe a secondary endpoint for details and a single boolean for "we still stand by this VC" 22:22:46 Orie has joined #vcwg-special 22:22:49 JoeAndrieu_: also think we have conflated the two things in an unfortunate way. calling it a status is the error. most verifiers don't care why they shouldn't verify it. just should i accept it or not. does the issuer still stand by it? 22:22:50 present+ 22:23:10 Verifiers are never required to review issuer claims... 22:23:17 q+ to note "one bit for should you accept this or not" and then a separate set of messages for "why" 22:23:23 q+ 22:23:32 q- later 22:23:39 dmitriz has joined #vcwg-special 22:23:43 ... a single boolean makes a lot of sense - like for drivers license. if a police officer pulls you over they don't care if it's suspended/revoked, just that it's still valid. maybe should separate into two. status list in the response shows you where you can get status messages. don't know what the best mechanism is. a simple binary mechanism is useful 22:23:56 ... separate out more privacy-risky attributes 22:23:59 ack Orie 22:24:35 Orie: glad we're saying the word 'verifier' so much. think we have language in the current spec that make it difficult around validation/verification. our spec does not create normative requirements for verifiers (as far as I'm aware) 22:25:02 ... don't need to check a digital signature, understand an algorithm, understand the entity is known/trusted, dereference key material, don't need to check statuses of credentials 22:25:19 q+ 22:25:43 ... say that because we want to correct this problem and it would require some additional responsibilities for verifiers. verifiers would now have to perform some operation on json to determine whether it is acceptable or not 22:26:14 ... can always ask a verifier to do these things, but they can decide they are not going to. our spec does not advise on how to use these properties. whether or not we support statuses in this way or another, we still have a problem of defining verification in a usable manner 22:26:17 ack manu 22:26:17 manu, you wanted to reiterate the problem w/ different types of status lists being expressed w/ the same type. and to note "one bit for should you accept this or not" and then a 22:26:20 ... separate set of messages for "why" 22:26:47 There are normative statements here: https://w3c.github.io/vc-data-model/#status 22:27:00 "The precise content of the credential status information is determined by the specific credentialStatus type definition, and varies depending on factors such as whether it is simple to implement or if it is privacy-enhancing." 22:27:47 manu: agree w/a lot of what Orie said. specifically went out of our way to not make them normative statements. wanted verifiers to be able to determine that. this PR raises how status list should interplay there. as JoeAndrieu_ said, there is a conflation in the spec now...not because of this PR, but it is bringing it to light. we want to have both things--(1) I still stand by this thing everything's good (2) I no lon 22:27:47 ger stand by this thing and here are messages that convey why 22:28:15 I think the normative statements in the core data model are untestable 22:28:21 ... need both and trying to do both in this PR is probably the wrong way to go about designing this. need to have a re-design discussion on how status list could change, re:Orie and JoeAndrieu_'s concerns 22:28:25 and need to be clarified, made testable... or removed. 22:28:34 which statements Orie? 22:29:00 hence different "statusPurpose" 22:29:01 all of them are untestable? 22:29:05 ... while revocation, suspension, informational messages are different status purposes they serve different needs. the first two are a "do I still stand by this or not" and the third is a mixture of the two 22:29:22 "id" and "type" part is testable (but useless): https://w3c.github.io/vc-data-model/#status 22:29:26 can we call this "informationalStatus" 22:29:33 ... feels like we should split this into those two categories: stand by credential and reasons why may not stand by this credential 22:29:54 ack mprorock 22:30:11 mprorock: question to Manu--can we call this informationalStatus for the status purpose? 22:30:18 manu: yes, a clear separation 22:30:36 q+ 22:30:41 manu: when you say informational status do you mean that completely---will not reject if any bits are flipped? 22:30:45 q+ 22:30:50 ack Orie 22:30:53 mprorock: will not tell someone what their business rules are, but will tell them it's informational 22:31:08 +1 orie 22:31:20 Orie: you can't tell a verifier what to do with this JSON. fundamentally this is the position the spec is in today 22:31:49 ... normatively can't tell a verifier to check a status. but do need to define what verification means 22:32:38 ... should concretely define what verification is, which cases lead to true or false with some reason. if we're not going to define all that, then don't see a different between informational and revocation/suspension 22:32:39 ack JoeAndrieu_ 22:33:08 This section is marked "informative" https://w3c.github.io/vc-data-model/#status-0 22:33:12 JoeAndrieu_: Orie was mostly aligned with what I'm about to say. hiccup which got me was about rejecting or not, which includes validate/verify. can't tell anyone how to validate--their business rules are up to them 22:33:17 q+ to request a set of possible proposals to move stuff forward 22:33:18 If the credentialStatus property is available, the status of a verifiable credential is expected to be evaluated by the verifier according to the credentialStatus type definition for the verifiable credential and the verifier's own status evaluation criteria. For example, a verifier can ensure the status of the verifiable credential is not "withdrawn for cause by the issuer". 22:33:35 ^ we say this *informatively* 22:33:40 ... we can say, if you are verifying here is what you must do, and if you don't you're not a conformant verifier. 22:33:51 ... we can say - if there's a property of this kind you must go check it as a verifier 22:34:01 This means implementers are not required to care about it... at al. 22:34:02 ack mprorock 22:34:02 mprorock, you wanted to request a set of possible proposals to move stuff forward 22:34:18 mprorock: brentz if OK with you would like to work on a set of strawmans to get feedback on to move this forward, mindful of time 22:34:24 brentz: yes, 20m left 22:34:43 Also fix https://w3c.github.io/vc-data-model/#dfn-verify 22:34:47 mprorock: concretely. remove mention of verify property from a status message and remove from examples. would that help improve this PR? 22:34:51 "his includes checking that: the credential (or presentation) conforms to the specification; the proof method is satisfied; and, if present, the status check succeeds. Verification of a credential does not imply evaluation of the truth of claims encoded in the credential.." 22:34:59 q+ 22:35:03 ack manu 22:35:15 manu: wouldn't object to it, but dlongley brought it up and he's not here 22:35:36 q+ 22:35:46 ... I am thinking we should remove revocation and suspension and unify across all the properties. need a chance to think through that from a privacy perspective 22:36:06 We have really, been bad, regarding normative and informative text in the core data model.... there are a lot of sentences, that should either be normative, or not be in the document, see https://w3c.github.io/vc-data-model/#dfn-verify 22:36:36 ... as Kristina said, if we merge to just a status mechanism we need to have some well known values like revocation and suspension, which raises the question about whether they need to be URLs, or strings...if we're going to re-design it'll take more than 20m 22:36:45 ack mprorock 22:37:21 mprorock: if we can get the PR merged we suddenly have the ability to attach a binary value to an arbitrary message. we then have a basis to ask some of those questions. if we don't we're blocking a whole bunch of implementations, which is frustrating. 22:37:41 q+ to comment on the working group progress on status list, and time table 22:37:50 ... assuming we approach it right let's not ask all questions up front but be open to amending after 22:37:57 ack Orie 22:37:57 Orie, you wanted to comment on the working group progress on status list, and time table 22:38:58 Orie: wondering if the vc-status-list work item, which the group has adopted, maybe it needs more incubation. maybe we should add reserved terms definitions under w3 org instead of w3c. if we can't make changes to the doc then maybe it needs to be matured further. so many work items to deliver on 22:39:12 ... would it be the end of the world if w3id.org defined these terms? 22:39:34 q+ to note that I don't think it would take more than 1-2 calls to work this out... and about incubation. 22:39:39 ack manu 22:39:39 manu, you wanted to note that I don't think it would take more than 1-2 calls to work this out... and about incubation. 22:39:47 kristina has joined #vcwg-special 22:39:50 present+ 22:40:05 +1 to move statusList2021 back to CCG for incubation 22:40:08 manu: I hesitate, it's a good suggestion if we had more time to do it. a number of us want to get this out there and done. don't think it'll take an enormous amount of work to refactor. maybe 1-2 calls to do it 22:40:57 if the WG questions the underlying premise of the status list draft at this point in time, it should go back to incubation 22:41:00 ...to unify it won't take a lot of time. can be done in parallel. can put multiple proposals together. a couple weeks to do it. can get the feature set more unified 22:41:05 q? 22:41:13 q+ 22:41:20 ack mprorock 22:41:22 ... -1 to going back to incubation 22:41:39 q+ to put a huge issue marker around everything and merge the PR. 22:41:44 mprorock: also -1 to moving it out. don't want to start another standardization process elsewhere to get it out. we have customers and governments looking to use it 22:42:19 q+ to suggest a separate property in the VC for status message, and one for verification only. Names TBD 22:42:22 ... if we pull verify item, and flag some issues, both manu and I are committed to getting this done and not wait until the next version 22:42:36 q? 22:42:39 ack manu 22:42:39 manu, you wanted to put a huge issue marker around everything and merge the PR. 22:43:08 q+ 22:43:19 manu: in the name of compromise what we could do is put an issue marker behind ttl, status message, draft alternative text and then just merge the PR noting clearly that we will modify to try to unify the spec more clearly 22:43:39 ack JoeAndrieu_ 22:43:39 JoeAndrieu_, you wanted to suggest a separate property in the VC for status message, and one for verification only. Names TBD 22:43:40 ... we want this in the spec just figuring out the best way to unify both approaches 22:43:51 +1 Joe 22:44:11 we really, really... need to fix the core data model, and its informative and normative guidance... 22:44:21 JoeAndrieu_: maybe we're in the wrong repo. semantics in vc-core we may need to fix. semantics need to go into the vc data model on to how get additional data, not this work item 22:44:22 ack mprorock 22:44:30 q+ 22:44:40 mprorock: 100% agree, may not be in the wrong repo, but 'what should i do as a verifier' should be in the core data model. 22:45:08 We are in the "right repo" for this "RDF type"... but the core data model says you don't have to care about it... at all, just need `id` and `type`. 22:45:10 ... manu if you open issues and link them then I will link them in the spec. where does that leave us? not a stretch, just an extension of binary 22:45:24 yes, I can open issues. 22:45:29 ack Orie 22:45:33 yes, it moves us forward wrt. merging. 22:46:10 Orie: agree with what Joe said. core data model said you need an id and type, not anything about what you'll do with those things. if you have different verifier behavior for every RDF type (what we're trying to say?) then I do think this needs to be fixed in the core data model and this status work item 22:47:17 brentz: course of action-moving forward - issues will be raised and issue markers added to this PR, then the PR will be merged. additional concerns related to this in the VCDM. let's check our existing backlog to see if there's already an issue, otherwise open a new one 22:47:33 related issue: https://github.com/w3c/vc-data-model/issues/1148 22:47:42 brentz: 8m otherwise we can call it a day 22:47:46 q+ 22:47:51 Related issue: https://github.com/w3c/vc-data-model/issues/991 22:48:06 ack mprorock 22:48:25 mprorock: my suggestion is we remove the notion of verifies as an additional property until core data model issues around how we handle this are resolved 22:48:32 ... any objection to this? 22:48:47 brentz: hear none 22:49:11 brentz: thanks all 22:53:37 zakim, end the meeting 22:53:37 As of this point the attendees have been brent, mprorock, decentralgabe, pl-ASU, JoeAndrieu_, manu, selfissued, hsano, Orie, kristina 22:53:39 RRSAgent, please draft minutes 22:53:41 I have made the request to generate https://www.w3.org/2023/06/20-vcwg-special-minutes.html Zakim 22:53:48 I am happy to have been of service, brentz; please remember to excuse RRSAgent. Goodbye 22:53:48 Zakim has left #vcwg-special 22:53:48 rrsagent, bye 22:53:48 I see no action items