15:53:29 <RRSAgent> RRSAgent has joined #vcwg-special
15:53:33 <RRSAgent> logging to https://www.w3.org/2023/01/24-vcwg-special-irc
15:53:33 <Zakim> RRSAgent, make logs Public
15:53:34 <Zakim> please title this meeting ("meeting: ..."), ivan
15:53:45 <ivan> Meeting: Verifiable Credentials Working Group Special Topic Call on StatusList2021
15:53:45 <ivan> Date: 2023-01-24
15:53:45 <ivan> chair: kristina
15:53:45 <ivan> Agenda: https://www.w3.org/mid/c8b8d2408867948fe40778ccc002877c@w3.org
15:53:45 <ivan> ivan has changed the topic to: Meeting Agenda 2022-01-24: https://www.w3.org/mid/c8b8d2408867948fe40778ccc002877c@w3.org
15:58:13 <TallTed> TallTed has joined #vcwg-special
16:00:58 <TallTed> TallTed has changed the topic to: Meeting Agenda 2023-01-24: https://www.w3.org/mid/c8b8d2408867948fe40778ccc002877c@w3.org
16:01:41 <brentz> brentz has joined #vcwg-special
16:01:51 <brentz> present+
16:01:56 <dlongley> present+
16:02:28 <cabernet> cabernet has joined #vcwg-special
16:02:32 <cabernet> present+
16:03:48 <Orie> Orie has joined #vcwg-special
16:03:51 <TallTed> present+
16:04:05 <JoeAndrieu> JoeAndrieu has joined #vcwg-special
16:04:08 <kristina> kristina has joined #vcwg-special
16:04:10 <Orie> present+
16:04:10 <kristina> present+
16:04:13 <JoeAndrieu> present+
16:04:15 <JoeAndrieu> scribe+
16:04:19 <Kerri_Lemoie_> Kerri_Lemoie_ has joined #vcwg-special
16:04:31 <PDL-ASU> PDL-ASU has joined #vcwg-special
16:04:35 <JoeAndrieu> kristina: Apologies the agenda was late going out.
16:04:37 <andres> andres has joined #vcwg-special
16:04:42 <PDL-ASU> +present
16:04:44 <JoeAndrieu> ... StatusList2021 is our focus.
16:05:11 <JoeAndrieu> ... We are trying to determine if we need to spend time on this in the F2F
16:05:23 <JoeAndrieu> ... No pressure. We'll go through the 20 issues and put labels on
16:05:41 <gregory> gregory has joined #vcwg-special
16:05:44 <kristina> q?
16:05:45 <JoeAndrieu> ... Two goals: where does the document sit and progress, and familiarize people with the work item itself
16:05:47 <Kerri_Lemoie_> present+
16:06:03 <JoeAndrieu> ... Ok. Let's dive in.
16:06:10 <gregory> present+
16:06:24 <brentz> zakim, start the meeting
16:06:24 <Zakim> RRSAgent, make logs Public
16:06:25 <Zakim> please title this meeting ("meeting: ..."), brentz
16:06:37 <brentz> meeting: VCWG Special call
16:06:41 <dlongley> present+
16:06:42 <Kerri_Lemoie_> present+
16:06:42 <JoeAndrieu> present+
16:06:42 <cabernet> present+
16:06:42 <TallTed> present+
16:06:44 <JoeAndrieu> scribe+
16:06:45 <manu> present+
16:06:45 <brentz> chair: Kristina
16:06:50 <JoeAndrieu> kristina: Apologies the agenda was late going out.
16:06:51 <PDL-ASU> present+
16:06:55 <JoeAndrieu> ... StatusList2021 is our focus.
16:06:58 <gregory> present+
16:06:59 <JoeAndrieu> ... We are trying to determine if we need to spend time on this in the F2F
16:07:04 <will> will has joined #vcwg-special
16:07:05 <JoeAndrieu> ... No pressure. We'll go through the 20 issues and put labels on
16:07:13 <JoeAndrieu> ... Two goals: where does the document sit and progress, and familiarize people with the work item itself
16:07:21 <JoeAndrieu> ... Ok. Let's dive in.
16:07:22 <kristina> present+
16:07:32 <kristina> Topic: issue tiraging
16:07:39 <kristina> subtopic: https://github.com/w3c/vc-status-list-2021/issues
16:07:51 <JoeAndrieu> ... Let's start with the first one
16:07:58 <JoeAndrieu> ... Issue 39
16:08:01 <kristina> subtopic: https://github.com/w3c/vc-status-list-2021/issues/39
16:08:13 <manu> q+
16:08:27 <JoeAndrieu> ... There are no comments. Just an example
16:08:40 <JoeAndrieu> ... So what do we do if the URL is a bad one?
16:08:47 <kristina> ack manu
16:08:58 <JoeAndrieu> manu: there's a difference between verificationa nd validation
16:09:14 <JoeAndrieu> ... verification is checking signatures... validation is different
16:09:30 <JoeAndrieu> ... Some verifiers might not care if the credential is suspended or revoked
16:09:40 <JoeAndrieu> ... So I think this is about validation not verification
16:09:47 <JoeAndrieu> ... We should provide some guidance about this
16:09:55 <JoeAndrieu> ... Probably in the StatusList spec, not the VCDM spec
16:10:08 <JoeAndrieu> ... If that sounds right, we could mark Ready for PR
16:10:10 <Orie> q+
16:10:17 <JoeAndrieu> ... But haven't had a chance to discuss yet.
16:10:36 <andres> Just a note - verification is defined in the spec as including that "... if present, the status check succeeds"
16:10:38 <kristina> ack orie
16:10:57 <manu> yes, andres, good point...
16:11:04 <JoeAndrieu> kristina: so you're saying if a verifier doesn't care, ignore the 404, if they do, it should fail.
16:11:19 <JoeAndrieu> orie: it's concerning that a verifier might not care
16:11:23 <dlongley> +1 to something along the lines of what Kristina said ... if the verifier cares about status and can't retrieve the status list credential, it should result in a validation failure
16:11:33 <JoeAndrieu> ... the status and id are two URLs that we need to define what they dereference to
16:11:35 <manu> ^ yes, +1 to that.
16:11:37 <JoeAndrieu> ... and what happens if they fail
16:11:40 <JoeAndrieu> q+
16:11:42 <kristina> q?
16:11:42 <manu> (to what dlongley said)
16:11:46 <manu> scribe+
16:12:31 <manu> JoeAndrieu: This may have been a scribe error, but what I heard in your summary Kristina, was about Verification, but what Manu noted was it's about "Validation". Orie is saying it should be a part of Verification, but Manu is saying, because it is a part of business rules, it's a part of Validation.
16:12:34 <dwaite> dwaite has joined #vcwg-special
16:12:38 <dwaite> present+
16:13:07 <manu> q+
16:13:07 <JoeAndrieu> kristina: I think we agree this isn't about validation. It's about business rules?
16:13:21 <dlongley> "validity of the credential" is "business logic" (as opposed to verification) ... at least that's how we've talked about it in this group in the past.
16:13:33 <kristina> ack JoeAndrieu
16:13:40 <kristina> ack manu
16:13:48 <JoeAndrieu> manu: I'm nitpicking on some of the language
16:14:03 <JoeAndrieu> ... it's not about business rules, it's about validation. But validation *is* about business rules.
16:14:18 <JoeAndrieu> ... Some of us are saying this is validation, which is where additional rules kick in.
16:14:32 <TallTed> +1 validation is about business rules, which may care about verification results *including* failures
16:14:37 <Kerri_Lemoie_> q+
16:14:42 <JoeAndrieu> ... Andres pointed out something interesting. If present, the status check needs to succeed, and it's not clear what that means
16:14:54 <JoeAndrieu> ... Need to clarify validation is about running a set of business rules
16:15:06 <kristina> ack Kerri_Lemoie_
16:15:09 <kristina> q+
16:15:09 <JoeAndrieu> ... And if the use case needs to vary based on status, that happens in validation
16:15:18 <Orie> q+
16:15:29 <JoeAndrieu> Kerri_Lemoie_:  are we sure its validation?
16:15:42 <JoeAndrieu> ... I thought verification is from what's in the space and validation is business rules
16:15:54 <manu> It's a good question, Kerri.
16:15:57 <JoeAndrieu> ... So, fit for role is a business rule, but the status is verification
16:16:00 <dlongley> our definition from the spec today: https://www.w3.org/TR/vc-data-model/#dfn-verify (not that it couldn't change)
16:16:04 <dwaite> q+
16:16:05 <JoeAndrieu> kristina: I think both are happening.
16:16:27 <JoeAndrieu> ... making sure there is a valid URL and checking it is "verification" and making a decision based on that is "validation"
16:16:29 <kristina> ack kristina
16:16:31 <kristina> ack Orie
16:16:44 <JoeAndrieu> orie: This issue is filed specifically for verification. We filed it.
16:16:59 <JoeAndrieu> ... If verifying is inconsistent, that leads to problems.
16:17:04 <manu> q+ to note what the spec says today.
16:17:11 <JoeAndrieu> ... Which will lead to different behaviors by different verifiers
16:17:17 <brentz> q+
16:17:27 <JoeAndrieu> ... If folks want to layer validation in front, that's fine. But this is a security issue about verification
16:17:28 <Kerri_Lemoie_> Reference we've been using for verification & validation: https://github.com/w3c-ccg/vc-api/blob/main/verification.md
16:17:37 <JoeAndrieu> ... about verifying a credential that is revocable
16:17:39 <kristina> ack dwaite
16:17:56 <JoeAndrieu> dwaite: Like a lot of things this is a condition of use that the issuer is setting
16:18:22 <gregory> q+
16:18:22 <JoeAndrieu> ... I think this should be in the main spec the same way that a verifier that accepts expired credentials... it may be a business decision but it still matters
16:18:24 <kristina> ack manu
16:18:24 <Zakim> manu, you wanted to note what the spec says today.
16:18:52 <manu> The spec currently states: https://www.w3.org/TR/vc-data-model/#status-0
16:19:05 <JoeAndrieu> manu: The current spec states... link. Status checking is a part of validation.
16:19:18 <JoeAndrieu> ... However, I agree that it is important that everyone does it the same way.
16:19:19 <kristina> q?
16:19:28 <JoeAndrieu> ... Where to put the language is a fair question
16:19:46 <JoeAndrieu> ... We might be able to waive our hands around what "must succeed" means
16:20:04 <kristina> q+
16:20:09 <JoeAndrieu> ... But I'm not sure how to do it, because if we have it in two places, we start to have validation creep into the VCDM
16:20:22 <Orie> q+
16:20:28 <JoeAndrieu> ... Hard decision either way. Status checking is part of validation. We don't say anyting about it in current VCDM
16:20:39 <JoeAndrieu> ... Not sure what language would solve the problem
16:20:40 <kristina> ack brentz
16:20:52 <kristina> zakim, close the queue
16:20:52 <Zakim> ok, kristina, the speaker queue is closed
16:20:56 <JoeAndrieu> brentz: I think there's a clear separation between validation and verification
16:21:18 <Orie> +1 Brent, its not possible to "verify" a revocable credential, unless this is defined properly.
16:21:19 <JoeAndrieu> ... You can't verify unless you can get the response from status list endpoint
16:21:25 <manu> +1 brent, that feels workable.
16:21:26 <Kerri_Lemoie_> Would any spec outside of VC but used as part of VC be considered validation instead of verification?
16:21:28 <JoeAndrieu> ... So we can say the status property must provide information.
16:21:28 <dlongley> +1 to brent
16:21:45 <JoeAndrieu> ... Whether the verifier does anything with that information, is a validation choice
16:21:47 <kristina> ack gregory
16:21:51 <andres> +1 to that
16:21:59 <kristina> q-
16:22:02 <JoeAndrieu> gregory: We have to cover some of the basic security and processing.
16:22:20 <JoeAndrieu> ... but if we get different credential rules about what is usable here or there, that models the real world
16:22:33 <kristina> ack Orie
16:22:49 <JoeAndrieu> orie: I'm confused by the comments about validation v verification
16:23:03 <JoeAndrieu> ... can I get clarity about whether or not the expiry date impacts verification
16:23:12 <brentz> q+
16:23:20 <JoeAndrieu> ... Whatever we say about validity date. That same sentence should be applied to this format
16:23:22 <manu> q+
16:23:22 <kristina> zakim, open the queue
16:23:23 <Zakim> ok, kristina, the speaker queue is open
16:23:32 <manu> q+ brent
16:23:32 <manu> q+
16:23:33 <JoeAndrieu> ... It's the intention of the issuer to communicate something essentially the same
16:23:49 <andres> both verification and validation are clearly defined in the vc-data-model spec
16:23:59 <JoeAndrieu> kristina: it looks like we need a new issue to talk about verification and validation
16:24:07 <kristina> ack brentz
16:24:08 <kristina> q?
16:24:14 <kristina> ack brent
16:24:16 <JoeAndrieu> brentz: I think the division is the same in both cases.
16:24:30 <JoeAndrieu> ... If there is a validFrom date, if that's there it needs to be a valid date
16:24:35 <JoeAndrieu> ... The verifier should check that
16:24:45 <JoeAndrieu> ... but if the verifier cares about that date is validation
16:24:47 <kristina> ack manu
16:24:49 <Orie> So "issuanceDate" and "credentialStatus" are equally the responsibility of the verifiers "validation process" ?
16:25:04 <JoeAndrieu> manu: what Brent said. That's a philosophy we can apply to all of these.
16:25:12 <JoeAndrieu> ... namely that it has to be syntactically valid
16:25:32 <JoeAndrieu> ... So the ID has to be a URL and we could add has to be dereferenceable and must get data back from it
16:25:44 <Orie> I think it "has to dereference to an object of the type noted by the list"... or it does not work.
16:25:49 <JoeAndrieu> ... Then, once you get into processing, that will be highly dependent on the type of Status List it is
16:26:06 <Orie> also the thing that is "dereferenced" needs to be verified....
16:26:11 <JoeAndrieu> ... Do we want to say something about the status check has to pass?
16:26:19 <JoeAndrieu> ... We do already say that in a validation section and status section
16:26:24 <Orie> +1 Manu, we do need to describe what the verifier does with the object that is dereferenced.
16:26:34 <Orie> or verifiers will handle it differently.
16:26:36 <JoeAndrieu> ... If the property is available, it is expected to be evaluated by the verifier
16:26:45 <dlongley> it has to be possible for the verifier to do the evaluation
16:26:51 <kristina> q
16:26:52 <kristina> q?
16:26:53 <PDL-ASU> +1 to Manu's suggestion.
16:26:55 <andres> q+
16:27:03 <manu> I will try to write something that makes sense, then :P
16:27:05 <andres> q-
16:27:11 <JoeAndrieu> kristina: looks like it is ready for PR for the beginning language. We can play with it once the PR is filed
16:27:14 <manu> I think I have enough to go on.
16:27:48 <JoeAndrieu> ... Going to the next issue, 38
16:27:56 <kristina> subtopic: https://github.com/w3c/vc-status-list-2021/issues/38
16:28:07 <JoeAndrieu> ... Should we discuss this or move on?
16:28:14 <JoeAndrieu> orie: I can provide some verbal update
16:28:25 <JoeAndrieu> ... This also applies to the behavior of the object that is dereferenced
16:28:40 <manu> q+ to note about TTL in HTTP Headers vs. in the actual object itself -- argue for actual object itself.
16:28:41 <JoeAndrieu> ... Imagine you get that list, how long should you hold on to it before you refresh?
16:28:53 <kristina> ack manu
16:28:53 <Zakim> manu, you wanted to note about TTL in HTTP Headers vs. in the actual object itself -- argue for actual object itself.
16:29:13 <JoeAndrieu> manu: time to live can be expressed in many ways, in HTTP headers or the object itself
16:29:20 <JoeAndrieu> ... I think we should put it in the object itself
16:29:35 <JoeAndrieu> ... The statuslist is signed by the issuer, so the holder can deliver that list to the verifier
16:29:48 <JoeAndrieu> ... as a more privacy preserving way to do it, especially for offline scenarios
16:30:12 <dlongley> +1 to Manu
16:30:14 <JoeAndrieu> ... So there's an argument for putting in the object itself so its clear no matter the delivery mechanism
16:30:18 <dlongley> +1 to just use validUntil and validFrom
16:30:25 <kristina> q?
16:30:29 <dlongley> q+
16:30:52 <kristina> ack dlongley
16:30:53 <JoeAndrieu> ... We could do both, but that seems like a bad idea.The real time-to-live should be in the object, which might be echoed in the header
16:31:09 <JoeAndrieu> dlongley: since the status list itself is a VC itself, we should recommend we just use those
16:31:09 <manu> +1 to reuse validFrom / validUntil
16:31:22 <andres> +1 to reusing
16:31:23 <JoeAndrieu> kristina: looks like we need more discussion? Or is it straightforward.
16:31:38 <JoeAndrieu> manu: could be ready for PR, if all we are doing is using validFrom/validUntil
16:31:45 <JoeAndrieu> ... So ready for PR, I imagine
16:31:54 <JoeAndrieu> kristina: ok, I don't see any objections to that
16:31:59 <kristina> subtopic: https://github.com/w3c/vc-status-list-2021/issues/37
16:32:07 <JoeAndrieu> ... Next issue #37
16:32:11 <Orie> q+
16:32:20 <kristina> ack Orie
16:32:36 <JoeAndrieu> orie: in earlier versions, it was only possible to have one status. just true/false
16:32:53 <JoeAndrieu> ... it's now possible to have multiple statuses, e.g., a DL that is revoked, suspended, or both
16:32:53 <manu> q+ to ask if we'll know the full list of statuses? Or just document to those we know of.
16:33:06 <JoeAndrieu> ... So what is the order that the verifier should process statuses?
16:33:16 <JoeAndrieu> ... I'll update the issue to clarify that
16:33:18 <kristina> ack manu
16:33:18 <Zakim> manu, you wanted to ask if we'll know the full list of statuses? Or just document to those we know of.
16:33:38 <JoeAndrieu> manu: The order of priority is revocation trumps suspension
16:33:53 <JoeAndrieu> ... The spec todays just defines suspension and revocation, but the field is designed to be openworld
16:34:00 <JoeAndrieu> ... people can put whatever status they want
16:34:00 <kristina> why is it legal to be both revoked and suspended at the same time?
16:34:13 <JoeAndrieu> ... because of that, I don't think we'll be able to have an order of priority for everyting
16:34:19 <JoeAndrieu> ... just for the things we define.
16:34:21 <kristina> q+
16:34:40 <JoeAndrieu> ... If someone creates a new type, its up to them to define how it fits with the existing status terms
16:34:45 <JoeAndrieu> ... I think its a bit of a corner case
16:34:56 <JoeAndrieu> ... I don't expect people to create all kinds of crazy forms of status
16:35:06 <JoeAndrieu> ... We should speak to revocation over suspension.
16:35:08 <dlongley> i don't think verification software needs to know this and could just report the status of all things ... leaving it to validation (business rules) to determine what to do from there
16:35:23 <JoeAndrieu> ... The other spec authors can explain how their new types fit it
16:35:33 <Orie> q+
16:35:48 <JoeAndrieu> kristina: why would a credential be both revoked and suspended?
16:36:12 <JoeAndrieu> ... We could say its undefined or if there are multiple states at the same time that's invalid
16:36:17 <kristina> q?
16:36:20 <kristina> ack kristina
16:36:23 <kristina> ack Orie
16:36:24 <JoeAndrieu> orie: I want to echo part of what manu said
16:36:29 <shawnb> shawnb has joined #vcwg-special
16:36:30 <brentz> could we make clear that there are possible invalid states?
16:36:32 <shawnb> present+
16:36:33 <JoeAndrieu> ... This is defined for open world application
16:36:52 <JoeAndrieu> ... While we defined those. Others might add a bunch of additional flags/terms
16:37:16 <JoeAndrieu> ... I think the issuer should be able to specify the intention and verifiers should be able to execute that order in a computationally efficient way
16:37:26 <JoeAndrieu> ... Revocation and Suspension are just two of many
16:37:34 <kristina> q?
16:37:39 <JoeAndrieu> ... We should not overfit to these two
16:37:54 <manu> q+ to answer Kristina's question.
16:38:00 <JoeAndrieu> kristina: We could say, the software returns the data and its up to the issuer to indicate the order.
16:38:13 <kristina> q?
16:38:14 <JoeAndrieu> ...is that good?
16:38:15 <kristina> ack manu
16:38:15 <Zakim> manu, you wanted to answer Kristina's question.
16:38:28 <JoeAndrieu> manu: why would a credential have two statuses?
16:39:02 <JoeAndrieu> ... Remember these things are issued, they are neither suspended or revoked. In the future, you might need to check both.
16:39:07 <kristina> q?
16:39:46 <JoeAndrieu> ... Orie raised a question. Yes this is open world, we can only specify what these two mean and their priority. He also said other things to be done and its up to the issuer to define order of importance.
16:39:54 <JoeAndrieu> ... we could do that by the ordering in the array.
16:40:07 <JoeAndrieu> ... The problem is that is currently an unordered set in the VCDM
16:40:14 <JoeAndrieu> ... So do we add a priority field?
16:40:27 <JoeAndrieu> ... Or is it just up to the verifier to figure it out
16:40:46 <JoeAndrieu> ... So we report both pieces of data, and its up to the verifier to decide how to process
16:40:47 <Orie> q+
16:41:02 <JoeAndrieu> ... Were you intending there to be an explicit order set by the issuer?
16:41:06 <kristina> ack Orie
16:41:16 <JoeAndrieu> orie: I would like for the issuer to be aware of what they are doing
16:41:34 <JoeAndrieu> ... If they are assigning over a set, then they need to understand order doesn't matter
16:41:47 <JoeAndrieu> ... I'm not sure which model we need, but the issuer needs to be clear about it
16:42:00 <JoeAndrieu> ... The point about the set is really important.
16:42:17 <manu> q+ to suggest "order is unimportant", 'cause people will get it wrong, and it's up to verifier to set the order of importance (first based on spec, then their own rules).
16:42:22 <JoeAndrieu> ... We have to be clear about our design decisions or they will just treat it as JSON, where order matters.
16:42:29 <JoeAndrieu> ... So we need to be clear
16:42:43 <TallTed> issuer might need to publish info about their statuses (ontology? priority? other?) that verifier can check along with the statuslist
16:42:44 <JoeAndrieu> kristina: I added the discuss label to the issue
16:42:47 <kristina> ack manu
16:42:47 <Zakim> manu, you wanted to suggest "order is unimportant", 'cause people will get it wrong, and it's up to verifier to set the order of importance (first based on spec, then their own
16:42:48 <Zakim> ... rules).
16:42:50 <JoeAndrieu> manu: We're almost to PR, I think
16:42:50 <Orie> If order is unimportant, we should say so :)
16:42:58 <kristina> q+
16:43:01 <JoeAndrieu> ... I'm going to suggest the order is unimportant
16:43:11 <JoeAndrieu> ... because implementers are going to likely get that wrong
16:43:18 <kristina> q-
16:43:23 <JoeAndrieu> ... and its up to the verifier to set the order of importance
16:43:34 <JoeAndrieu> ... but the spec will clearly say that revocation is more important
16:43:45 <JoeAndrieu> ... then verifiers can add their own rules after
16:44:00 <TallTed> now we're defining business rules?
16:44:01 <JoeAndrieu> ... so revocation first, then suspension, then any additional rules
16:44:25 <JoeAndrieu> ... We are defining the validation rules Orie says is imporant
16:44:44 <JoeAndrieu> tallted: I get that some people is desiring that. I don't think we should be dictating it in this way.
16:45:04 <JoeAndrieu> ... I'm ok with someone saying revoked trumps everything
16:45:14 <JoeAndrieu> ... but there are use cases where that isn't true
16:45:46 <manu> hrm, them perhaps: "status is reported back and the verifier makes the decision on order of importance, with suggestion that revocation is more important than suspension."
16:45:48 <TallTed> s/someone saying revoked/someone deciding revoked in their ecosystem/
16:45:49 <JoeAndrieu> kristina: I sense more confusion than clarity. I don't think we are ready for PR
16:46:03 <kristina> subtopic: https://github.com/w3c/vc-status-list-2021/issues/36
16:46:07 <JoeAndrieu> ... ten minutes left. one more issue #36
16:46:15 <manu> q+
16:46:21 <kristina> ack manu
16:46:25 <JoeAndrieu> manu: yes, we should do this
16:46:29 <brent> brent has joined #vcwg-special
16:46:40 <JoeAndrieu> ... we already have examples of implementers interpreting this differently. Ready for PR
16:46:43 <kristina> q?
16:46:47 <JoeAndrieu> kristina: any objections?
16:47:03 <JoeAndrieu> ...[none were heard]
16:47:08 <brentz> I would call them processing rules. Once processed, the Verifier can still determine whether the information applies to its internal validation rules.
16:47:09 <Brian> Brian has joined #vcwg-special
16:47:19 <kristina> subtopic: https://github.com/w3c/vc-status-list-2021/issues/23
16:47:25 <JoeAndrieu> ... issue 23
16:47:51 <JoeAndrieu> ... It's a tricky, legal oriented discussion. Last comment said ready for PR
16:47:54 <JoeAndrieu> ... Is it?
16:47:58 <kristina> q?
16:48:14 <shawnb> q+
16:48:14 <JoeAndrieu> ... Shawn?
16:48:20 <kristina> ack shawnb
16:48:31 <JoeAndrieu> shawnb: This is something I raised early on.
16:48:45 <JoeAndrieu> ... I have a set of privacy legal experts I can task to help make a PR
16:48:49 <manu> q+ to note "ready for PR"
16:48:53 <JoeAndrieu> ... Happy to take this on
16:48:54 <kristina> ack manu
16:48:54 <Zakim> manu, you wanted to note "ready for PR"
16:49:14 <JoeAndrieu> manu: I think this is ready for PR, Shawn if you can move this forward with legal experts, that would help
16:49:20 <shawnb> Sounds good
16:49:33 <JoeAndrieu> kristina: thanks shawn. added Ready for PR
16:49:40 <kristina> subtopic: https://github.com/w3c/vc-status-list-2021/issues/12
16:49:43 <JoeAndrieu> ... issue 12
16:50:00 <manu> q+
16:50:02 <dlongley> q+
16:50:05 <kristina> ack manu
16:50:06 <JoeAndrieu> ... Adding reason field. Which sounds useful.
16:50:16 <JoeAndrieu> manu: I agree it would be useful
16:50:22 <JoeAndrieu> ... but I'm concerned about size
16:50:40 <JoeAndrieu> ... The whole point is of Status List is to scale well
16:50:49 <JoeAndrieu> ... Also, it leaks privacy
16:50:53 <gregory> q+
16:51:00 <JoeAndrieu> ... And is the reason just an open text?
16:51:21 <JoeAndrieu> ... The issuer should keep track of why, and they should be able to explain why to the appropriate parties
16:51:34 <JoeAndrieu> ... That's between the individual and the issuer, not information that is publicized
16:51:40 <JoeAndrieu> ... Presently, I'd be -1 to this
16:51:46 <JoeAndrieu> ... Because the use case isn't clear
16:51:56 <JoeAndrieu> ... and we don't have enought experience to say what all the codes would be
16:51:59 <kristina> ack dlongley
16:52:21 <JoeAndrieu> dlongley: Agree with manu. This seems like something that is very hard to do while preserving the privacy of the holder.
16:52:32 <kristina> ack gregory
16:52:35 <JoeAndrieu> ... solving this in a general way that won't be abused is fraught
16:52:52 <JoeAndrieu> gregory: echoing Manu. At least in Canada, you could run into real problems with privacy law.
16:53:11 <JoeAndrieu> ... it may not be your concern that its suspended for repeat DUI verses something less serious
16:53:14 <kristina> q?
16:53:44 <JoeAndrieu> kristina: let's document that there's no consensus on adopting this feature and we can revisit later
16:53:56 <JoeAndrieu> ... with two minutes left
16:54:20 <kristina> subtopic: https://github.com/w3c/vc-status-list-2021/issues/8
16:54:30 <manu> q+
16:54:35 <JoeAndrieu> ... Issue 8
16:54:39 <kristina> ack manu
16:54:42 <JoeAndrieu> ... Looks like debates about issue.
16:54:43 <dlongley> this is a duplicate
16:54:48 <JoeAndrieu> manu: This looks like a dupe
16:54:55 <JoeAndrieu> kristina: Ok, we'll close it as a dup
16:55:06 <JoeAndrieu> ... Thanks everyone. That was a productive discussion
16:55:19 <JoeAndrieu> ... Looking forward to reviewing PRs in main call
16:55:32 <JoeAndrieu> ... See you all tomorrow at the same time
16:55:40 <dmitriz> dmitriz has joined #vcwg-special
16:56:42 <kristina> rrsagent, draft minutes
16:56:43 <RRSAgent> I have made the request to generate https://www.w3.org/2023/01/24-vcwg-special-minutes.html kristina
16:56:59 <kristina> zakim, end meeting
16:56:59 <Zakim> As of this point the attendees have been brentz, dlongley, cabernet, TallTed, Orie, kristina, JoeAndrieu, present, Kerri_Lemoie_, gregory, manu, PDL-ASU, dwaite, shawnb
16:57:02 <Zakim> RRSAgent, please draft minutes
16:57:03 <RRSAgent> I have made the request to generate https://www.w3.org/2023/01/24-vcwg-special-minutes.html Zakim
16:57:09 <Zakim> I am happy to have been of service, kristina; please remember to excuse RRSAgent.  Goodbye
16:57:09 <kristina> rrsagent, bye
16:57:09 <RRSAgent> I see no action items
16:57:09 <Zakim> Zakim has left #vcwg-special