Verifiable Credentials Working Group F2F at TPAC, 2nd day — Minutes

Date: 2023-09-15

See also the Agenda and the IRC Log

Attendees

Present: Shigeya Suzuki, David Ezell, Pierre-Antoine Champin, Ivan Herman, Brent Zundel, Ted Thibodeau Jr., Kristina Yasuda, Gabe Cohen, Andres Uribe, Hiroyuki Sano, Joe Andrieu, Manu Sporny, David Chadwick, Jay Kishigami, Chris Needham, Geunhyung Kim, David Waite, Kevin Dean, Michael Jones, Dmitri Zagidulin, Paul Dietrich, Benjamin Young, Dave Longley, Sebastian Crane

Regrets:

Guests: Kazuyuki Ashimura, y-sakuma, Sam Goto, Ryuichi Matsukura, doniv, Laurens Debackere, Wonsuk Lee, Rick Byers, helen, Nick Doty, Kazuyuki Ashimura,

Chair: Kristina Yasuda, Brent Zundel

Scribe(s): Sam Goto, Manu Sporny, Brent Zundel, Paul Dietrich, Sebastian Crane

Content:

Brent Zundel: For today: status list, presentation after the break from web wallets, conversation with ping, open issues with privacy reviews, after lunch break candidate rep for each specification, and then remaining time test suites.

1. VC-StatusList.

Brent Zundel: https://github.com/w3c/vc-status-list-2021/labels/before-CR.

Brent Zundel: vc status list, doesn’t have open PRs, merged most recent one this morning, we need to determine what needs to be done, who is going to do it and by when …

1.1. Split design space into two different types of status lists (issue vc-status-list-2021#85)

See github issue vc-status-list-2021#85.

Manu Sporny: issue 85 … raises the question on whether or not to split the design space … status list was on an easy trajectory …. then additions by folks in the supply chain traceability space … modifying the single bit into a multi bit status … to contain a message effectively, and then have an arbitrary number of messages with the particular status entry … including links to documentation and business rules … time to live … variety of oth[CUT].

Brent Zundel: iirc it was already multi-bit, but the additions were the optional additional information and the ability to define statuses by those setting up the list.

Manu Sporny: in hindsight that has had unanticipated effects … status list not as simple as before …
… if we want to do privacy preserving things, add noise to the bit, the width of the status list … can affect how we’ll add noise to the list … you’d have to flip the right bits in a statistically significant way …
… i’m suggesting that we create two different lists, one of them a very simple status list, much easier to do the privacy analysis on it … and then have a separate status list, multi bit, with all of these other features … different privacy characteristics … “please be aware” … i think it will be easier to write the specification …

Brent Zundel: as far as the privacy concerns … when issuing … don’t think the characterization of single bit vs multi bit is quite accurate …. it was always multi bit IIUC …
… suggestion on the floor to move in a different direction … anyone opposed to having two different lists?

Kristina Yasuda: only raised recently, so not the moment to make decisions …. single bit vs multi bit doesn’t seem like it would change the privacy analysis …
… we need to understand a bit more before we arrive at a conclusion / agreement.

Gabe Cohen: 1+ to single type.

Andres Uribe: i agree with kristina …. i recommend that we don’t have multiple types …. makes it hard for people to make a decision on which one to use …
… if you are able to correlate with a single bit you’d also be able to correlate with multi bits …

Kristina Yasuda: there is interest to use multibit one for people too.

Manu Sporny: what’s the use case for that kristina ^.

Kristina Yasuda: -1 to binding singleBit/multiBit to the use-case.

David Chadwick: not sure i see a different problem with having two lists.

Kristina Yasuda: even for people there are cases when more than 2 statuses needed.

Joe Andrieu: i think it applies to more than the human privacy issue … the bit shows up in other problems … we could have solved this in other ways other than multi-bit …

Manu Sporny: yes, but what’s the use case for that ^ – like, what statuses are we setting for people?

Joe Andrieu: with the multi bit you are checking … i’m curious why you don’t think single bit vs multi bits isn’t the key of the concern …

Brent Zundel: framing it as a single bit vs multi bit is disingenuous.

Manu Sporny: +1 what joe said …
… on the privacy issue, when you expose more information on an entity … things get dicier and dicier from a privacy perspective … e.g. maybe it is the wrong framing … happy to use other words ,… the concern here is that if we have, maybe a bigger conversation, when you have the possibility to have multiple bits … of data on an individual … having one bit of data is simpler than 10 different statuses on an individual …
… the person didn’t show up because they didn’t renew their driver’s license … shipping containers … why was it held for inspection … it can be OK for a non-person object, but certainly, more thought needs to be put for individuals …
… this concept where we are going to have an arbitrary number of statuses associated of entities … it makes the design space more complicated, in comparions to single bit. either we split the design space … another option, same design space …
… then we have to be explicit about the dangers of having multiple bits, because you have more data points on the entity …. ideally down to a single bit … e.g. revoked or not, rather than reasons .
… if you are going to have 10 different reasons for why it was revoked … you have to do that in a statistically different way …
… these new changes have made it more complicated … we have to think this through … the easiest way i think is to have two different types …
… the other approach is to have everything the same but gets more complicated.

Kristina Yasuda: i seriously question the notion within the status list use case and specification that more data points about the user instead of just one bit being used rather than two bits for valid or invalid leads to more correlation … that is not correlation comes from in the three party model … it comes from the identifiers …
… correlation between the verifier, the issuer, privacy from whom? who are we violating the privacy?
… are you worried about the verifier getting more information and therefore getting more?
… if that’s the issue, then we shouldn’t be doing at all. so don’t think the notion is accurate.
… don’t disagree that simple bit is simpler than many … but it doesn’t seem complicated enough to justify a new type …
… can we separate for people and not-people?

Gabe Cohen: i agree with the sentiment that we should limit footguns …
… i don’t think privacy is a matter of opinion here … we can get experts who can do a better privacy analysis … so suggestion is to reach out and report back to the group.
… preference is to have a single option, makes implementation harder if we have many.

Shigeya Suzuki: +1 to what gabe said.

Andres Uribe: agree with gabe.

Brent Zundel: back to concrete proposals, status list, the spec, be separated into two different types …. we don’t have consensus to do that to make that change …. based on the conversation … the argument that the work is greater if we don’t split it isn’t convincing to me …. seems like we’d have to do the same amount of work either way …

joeandrie: +1, doesn’t seem like consensus …

Joe Andrieu: it could be different lists … topologically, you’d have to look at the VC … whereas if multi bit …
… the topology could be that you have one VC that points to three lists … revocation, suspension, etc.

joeandrie: or you could have one VC with 3 bits …

Joe Andrieu: we are not going to get consensus atm.

Kevin Dean: privacy application to individuals vs corporations … corporations may have the same concerns … that you could apply to personal data … same concerns to non-human side of VCs ….

Kristina Yasuda: there 3 bits are about the same user by design - they are correlated by design.

Kristina Yasuda: +1 kevin.

Manu Sporny: yes, and that’s the problem ^.

Joe Andrieu: +1 to information security ~= organizational privacy.

Gabe Cohen: why is intentional correlation a problem? what does it erode?

Manu Sporny: understand that we are not going to get consensus to split … so … i’ll proceed by trying to address this in spec text ….
… and privacy considerations … this is one of the reasons pushing why pushing PRs and then dealing with the problem in the future ,….
… in any case, i’ll proceed by writing in the privacy consideration section …
… one of the problems here is correlation of population … the list is composed in a particular way … what the populations may be doing …

Ted Thibodeau Jr.: +1 this is why I frequently argue against merging something with known flaws that “we can sand off later”.

Brent Zundel: as to this issue, can it be closed? or should it remain open?

Manu Sporny: lets open a new one while we are here.

Brent Zundel: lets move on to our next issue.

1.2. Cascading status updates (issue vc-status-list-2021#84)

See github issue vc-status-list-2021#84.

Brent Zundel: suspension of a root credential should cause a child credential to fail …. does anyone have this problem too?
… the relationship status … question about statuses of multiple credentials … combinatorial status …
… need to get recommendations or just chat?

Kevin Dean: … if my credential is revoked … it may have an impact on credentials that i have issued …
… … any credentials i issued up to that point … in rare circumstances it may affect credentials i issued in the past …

Gabe Cohen: that seems like a legitimate need …
… seems like a protocol-level decision …
… another spec another place may be better.

Brent Zundel: +1, agree that this is a problem, not sure that status list 2021 is the right place to do that specification.

Kristina Yasuda: +1, agree this is about how the issuer manages multiple credential statuses.

Brent Zundel: not even sure if it is within the scope of the charter that it is …
… we are short on time ,..

Gabe Cohen: more broadly dependent/complex validation logic is ill-defined.

Manu Sporny: yes, i’d echo what gabe and brent and kristina had said on irc …
… maybe this is language that could go in the VC data model … i don’t think this is something that the status list spec should talk about ,….
… even if it does, it would have to be non-normative …

Paul Dietrich: What is relevant to status spec is that the multi-bit options for status could affect business logic during validation.

Brent Zundel: recommending that it remains open?
… or close?

Manu Sporny: orie?
… not pre-cr, post-cr … my suggestion is seeing if orie objects to closing it …

Kristina Yasuda: we heard that there are use cases for that …

Joe Andrieu: i have the same question … what’s the proposed mechanisms? i think this really goes in implementation guide …

Kevin Dean: +1 to Joe.

Ted Thibodeau Jr.: VC allows me to know that “Joe said something”.

ted: some metadata, dates, etc, but the full infrastructure that’s required for whether something is revoked is not built into this, do not recommend it.

Dmitri Zagidulin: @TallTed - not sure I fully understand? credentialStatus is an integral part of VCs..

Brent Zundel: labelling it to “pending close”, orie can comment and we can go from there.
… unclear what normative changes would be required.
… next, talking about 82.

Ted Thibodeau Jr.: dmitriz — What happens if your credentialStatus lookup fails? once? 3 times over 7 days? This is business logic.

1.3. auto-publishing using echidna? (issue vc-status-list-2021#82)

See github issue vc-status-list-2021#82.

Brent Zundel: intro, spec from april, fix for this is straightfoward, we need to go back to call vc status 2021 … unless we as a group change the record name …

Brent Zundel: we either change it back or we have a formal resolution to change the name …
… ivan and the editors …

Manu Sporny: just need to change the name of the spec … no longer vc status list 2021 … use something less generic.

Dmitri Zagidulin: @TallTed - sure, that’s business logic. I’m just wondering why you’re saying “VCs weren’t designed for this”. business logic is a huge part of VC validation, it’s absolutely designed for it.

Manu Sporny: maybe vc multi status list … vc stream status list …
… hesistant to change it today.
… interested in time boxing it.

Brent Zundel: 2 mins.
… if something can come up with a good name in the next 2 mins.

Andres Uribe: I likevc-bit-string-status-list.

Kristina Yasuda: why is this so complicated? why can’t we just remove 2021 from the name?

Brent Zundel: that would work.

Manu Sporny: -1.

Gabe Cohen: +1.

Dmitri Zagidulin: +1.

Brent Zundel: would that work for everybody?
… anyone opposed?

Manu Sporny: yes, too generic.

Andres Uribe: 0 (prefer vc-bit-string-status-list).

Manu Sporny: bit string status list.

Brent Zundel: anyone opposed?

Kristina Yasuda: i do think you need status list of “what”?

Brent Zundel: no one wants to die on the hill.
… i’ll draft a proposal.

Manu Sporny: there is also … nevermind.

Kristina Yasuda: what was manu’s proposal?

Joe Andrieu: seems like misalignment between two names …

Ivan Herman: lets not rename the doc in three months … lets do them both at the same time …

Proposed resolution: the new shortname is vc-bitstring-status-list. (Brent Zundel)

Manu Sporny: +1.

Gabe Cohen: +1.

Joe Andrieu: +1.

Shigeya Suzuki: +1.

Ivan Herman: 0.

Dmitri Zagidulin: +1.

Andres Uribe: +1.

Brent Zundel: +1.

David Waite: +1.

Ted Thibodeau Jr.: +0.

Hiroyuki Sano: 0.

David Chadwick: +1.

Kristina Yasuda: 0.

Jay Kishigami: 0.

Paul Dietrich: 0.

Resolution #1: the new shortname is vc-bitstring-status-list.

Brent Zundel: not seeing any opposition.
… we are resolved.
… practical level, who is going to fix the spec.

Ivan Herman: who wants to help?

Manu Sporny: i can help.
… i can do the naming changes.

Ivan Herman: i have put a comment into the issue where i summarized what we need to do in the COSE/JOSE change.

Brent Zundel: good conversation … we still have like 25 issues to look at.
… and 30 mins to do it.
… if the editors have preferences for how to prioritize …
… take advantage of the people in the room.
… jumping into 81.

Manu Sporny: skip that.

1.4. Add section on expected server HTTP status codes (issue vc-status-list-2021#64)

See github issue vc-status-list-2021#64.

Manu Sporny: need approval from the group to talk about potential http response status codes … request by mike jones.
… if you do things with status lists with HTTP, what should you expect …
… from HTTP status codes …
… if you operate over http these are the things that you can expect to see from servers ….
… looking to see if anyone that would oppose to adding a section on operating over http and expecting http error codes.

Brent Zundel: any opposition as that for a path forward?

Kristina Yasuda: sgtm.
… when this was raised we deliberately didn’t do right away … what has changed? why is it ok to do this now?

Joe Andrieu: just wanted to clarify, the intention is to not use non-normative language, right?

Manu Sporny: what has changed, kristina, is that we figured out a way to do it without raising objections, a design pattern in the status list that people din’t reject.

Kristina Yasuda: it needs to be normative.

Manu Sporny: joe, if you are using HTTP these things MUST be done.

Joe Andrieu: +1 to normative. just wanted to understand the scope of the proposal.

Brent Zundel: prefer normative, since we’ve found a way to do that.

Manu Sporny: mike, wdyt, would you more normative language around this?

mike: yeah.

Manu Sporny: as long as no one opposed, we’d use normative language.
… i’ll take that.

1.5. Encoded list in Base64 or Base64Url? (issue vc-status-list-2021#58)

See github issue vc-status-list-2021#58.

Manu Sporny: lets do 58 next.
… should we use base64 or base64url to encode the list.
… orie says we should say base64url, anyone opposed?

Brent Zundel: no one on the queue, you are good to go.

Manu Sporny: neat, i can take it.

1.6. clarify protocol for retrieval of a status list (issue vc-status-list-2021#44)

See github issue vc-status-list-2021#44.

Manu Sporny: clarify the protocol …. for — list …
… unless anyone objects … it should be http-over-url.
… should be simple … people can use different protocols …

Kristina Yasuda: i have not heard anyone sending status lists over PE.

Manu Sporny: should be expressed … should be able to be retrieved over http … anyone disagrees?

Joe Andrieu: binding a resource to its transport type is flawed … not sure it makes sense …
… if i see a status list … it can be FTP …

Brent Zundel: i agree with you, and was happy when manu said SHOULD.

Andres Uribe: i’d like to see HTTPS.

Brent Zundel: of course.

Kristina Yasuda: do we also how the url is being fetched? post/get?

Manu Sporny: yeah, good questions … this is where it gets complicated … just say … yon should use a HTTPS url, but that doesn’t mean that you can’t use FTP or ssh:// …
… preferring to use oblivious http, rather than plain http … that’s where it gets more complicated …. recommending … we’ll just have to work on the details on the PR …
… the more prescriptive we get the harder the PR is.
… right place to work on that is in the PR … would that work?

Kristina Yasuda: assuming you are the one writing the pr … are you going to specify whether it is going to be a GET or POST?

Manu Sporny: i think it is goin to be a GET.
… lets say, a GET, ideally over oblivious HTTP, no query parameters, no fragment identifiers … any objections?

Sam Goto: ?

Kristina Yasuda: hard to say right now if that works …
… sounds reasonable … intuition feels like there is something out there already …

Kristina Yasuda: i have questions on actually recommending OHTTP - it is still in draft in IETF. not comfortable with that.

1.7. Can the spec relax/remove the requirement on minimal bit length? (issue vc-status-list-2021#14)

See github issue vc-status-list-2021#14.

Manu Sporny: asks if we can relax / remove the requirement on the minimum bit for the status list …
… currently 16 KBs.
… the concern here is around privacy …. providing at least a minimum …
… do we want to leave the hard privacy decision to the implementors?
… some authors of the status list may pick minimum population sizes that do not provide hard privacy?
… or at least we could provide a floor.
… do we want a minimum guaranteed privacy setting for these lists?
… or do we want ot leave that open to authors? understanding that they can pick bad values.

Gabe Cohen: +1 keep the floor.

Joe Andrieu: i agree that it is arbitrary.
… but i do agree that we need a floor.
… most people use defaults, should be a good one.

Manu Sporny: the current number is arbitrary.
… we took 16 KBs and run through gzip …. seemed reasonable …
… we could increase/decrease … but very strongly arguing that we should have a decent floor.
… since we are going to multibits … we should try to get good defaults.
… responding to dwait, the verifier shoud reject.

Kristina Yasuda: we can’t make a decision right now, need input from implementors …

Joe Andrieu: we should ask a specific use case … maybe it is an iot situation where size matters …
… i’ll add that comment.

Brent Zundel: action is to do nothing, see if we hear back.

1.8. Should “noise” be added during “updates” (issue vc-status-list-2021#40)

See github issue vc-status-list-2021#40.

Manu Sporny: decoys or noise when the initial publication happens and when you see updates.
… concern is, adversary looking at the list, watching bits flip, downloading the list every 5 mins, they can see what percentage of your population is having things revoked or changed or modified and gives them insights into your population.
… … are operating … they would undrestand … 30% of the population broke the law in some way ….
… they can figure out what the population is doing ….
… one way to address this is to add noise to the list.

Kristina Yasuda: describing the problem is sufficient in privacy considerations.

Manu Sporny: implementor specific … publisher of the list decides on how to add noise and in what order …. creates variation … there is no one algorithm to add noise … the downside is taht the implementor may not have privacy experts …
… so easy for them get wrong and reveal more information.
… do we want to tackle noise generation or do we want to leave that to implementors?

Brent Zundel: this exists because of the architecture itself …. strongly in favor of option 2 … even if we find a good way to do this, in a few weeks a better one would come up …
… there are going to be confusion, but it doesn’t feel like we have enough information in the group …
… so, a note somewhere on how to go about noise.

Kristina Yasuda: yeah, in general agree … what mechanisms are currently used?

Kristina Yasuda: it is hard.

Manu Sporny: they are not doing this at all, as far as we can tell. we heard it is on the roadmap, but no one is doing it.
… e.g. revocation status list, you’d never want to flip a revocation bit, because that would give away that that entry is a decoy.
… so you have to be careful. it becomes even more important with multi-bits.

Kristina Yasuda: well, driving licenses can be temporarily revoked for 30/60 days etc so flipping back is fine.

Manu Sporny: +1 to agree with everything that has been said so far, we don’t have enough implementation experience to decide,.

Kristina Yasuda: no advising, just describing the problem is sufficient.

Manu Sporny: no specific recommendation for the path, but htings that implementors should be worried about.

Brent Zundel: post cr and move on.

Joe Andrieu: not to advise, really we haven’t figured outk, but things to consider.

1.9. Clarify that StatusList2021Credential must be VC-DATA-MODEL (v1.1) (issue vc-status-list-2021#51)

See github issue vc-status-list-2021#51.

Manu Sporny: clarify if VC data model, what are we targeting?

Kristina Yasuda: clarification i’m looking for is the shape of a status list.
… examples using VC data model, but no where in the doc it says that it must be compliant.
… is it reallly the VC data model?
… doesn’t seem like it needs to be compliant with the VC data model.
… doesn’t have info about the holder …
… sitting on a HTTPS url.
… i’d prefer if this was a simple JWT.
… not sure if i can convince this group to go in this direction.
… so looking for clarity.

Manu Sporny: yeah … it is definitely VC data model.

Kristina Yasuda: like what?

Manu Sporny: we rely on a variety of things, in the status list.
… there is a use case where the holder takes this.
… for the purposes of privacy protections.
… so that the verifier doesn’t have to go out and fetch it.
… to be clear, we depend on things like the issuer … valid from and valid until … credential subjects …
… not easy to put into a JWT.
… that said, you can encode it into a JWT.
… but the data model, it is highly dependent on the VC data model.

Joe Andrieu: first i thought that made sense kristina, but then realized that …

Kristina Yasuda: the way i differentiate it … it is independent of the data model of how the status list is expressed …
… for example, if there is a CBOR based credential.
… technically, the status list doesn’t need to be CBOR.
… i’ve seem people doing that.
… there is a sepearation of HOW things are expressed and WHAT things it epxresses.

1.10. Vocabulary definitions (issue vc-status-list-2021#81)

See github issue vc-status-list-2021#81.

Ivan Herman: there are a number of properties that are defined in the standard and are used from within JSON-LD, they must be added to a vocabulary….
… we need the range, domain, etc.

Kristina Yasuda: that problem goes away if the status list credential is not a vcdm :P.

Manu Sporny: two options: put in the VC vocabulary … exists and is there … another option is to create a different vocabulary doc … for the status list spec …
… and put it in that.
… on the fence on what to do …
… the second approach seems cleaner … but more pain ,…. vs just putting in the VC vocab easier to do.

Brent Zundel: anyone opposed to the VC vocab?

Ivan Herman: the credential vocab is already a collection in a sense.
… not to the VC DM only.
… so putting into that vocabulary is “clean enough”.
… not devoted into any of the two options.

Joe Andrieu: just wanted to note that it is a VC and we support VCs over JWTs …

Brent Zundel: manu and ivan seem to be on the same page …

Manu Sporny: ivan, what would you prefer?

Brent Zundel: the point is that that’s a conversation beteween the two of you.

Ivan Herman: inclined to put in the VC vocab.

2. WICG and Web Wallets.

Brent Zundel: We have invited folks from the WICG to discuss Identity Credentials work.

Rick Byers: I work at Chrome, work with Sam Goto - work on Federated Identity – Helen who works on Android:* rickByers: I work at Chrome, work with Sam Goto - work on Federated Identity -- Helen who works on Android.

Rick Byers: Some caveats – I work on browser APIs, not a credential expert – lots of specs, lots to learn, apologize for not engaging this group sooner. Realized that we ran forward without reaching out to you, apologize for that.

Rick Byers: See slides: https://docs.google.com/presentation/d/1mz7AUJLc9y7zOU7CfLCsBSt3dGIkN_x61tpoRaQCQko/edit?resourcekey=0-NhvH5WIUclnZZPyRSyyLqQ.

Rick Byers: I’m here mostly representing chrome and android, lots of different interests.
… I’m going to focus on Chrome goals, even though we’re working w/ other browser vendors. This is just what we think this week… looking for feedback,, don’t ake any of this as a guaranteed promise in any way.
… What we think our goals are: wallet discovery and invocation – that’s not a completely solved problem, trying to help websites request credentials from wallets.
… we are not interested in trying to pick one wallet – want a multi-wallet approach and easy for users to have multiple wallets – we’re worried about individual having credential, but they forget which wallet that credential is in… in some scenarios, they can go directly to credential.
… We’re very concerned about privacy in general, we need meaningful consent from people before wallet is invoked – high level principle is the more we can be confident that user understands the context, the lower friction we can have for user.
… We want to enable things that are difficult w/o browsers – cross-device requests, like passkeys today, can make it seamless for websites… we want to enable competition and choice in credential formats and wallets – one format vs. other format – not proper position for platform to be in – we need to enable level playing field, have issuers/users choose what’s best for them.

Manu Sporny: this all looks great. enabling consent, choosing wallets, etc. great to see chrome team engaged.
… also great to hear not picking winners on credential formats. maybe should pick protocols or query languages.
… I’ve talked with sam before about CHAPI which is a plugin that does a lot of this.
… are you planning on focusing on one way through to start? Like starting with mDL first and foremost? what is the charter like, are you looking at other formats like VCs etc.?

Rick Byers: It’s true that when we started we were focused on mDL, but Sam convinced us that’s the wrong approach thanks to work you (the grop) have been doing.
… Our current prototype is format agnostic, code doesn’t know about formats at all, have to do minimum amount in chrome mto understand request to get meaningful consent, but we think that’s minimal, don’t see why we can’t do that for VCs and mdocs at the same time, details to work out – query language, our principle is we need to understand enough about query in browser to give low friction high confidence flow – vs. option that might be a bit scarier – there is always mechanisms for wallets to alk directly to websites… QR Codes, custom URL schemes – we need to create enough trust in our approach to have RPs to choose to use our APIs, but have scenarios where other routes are used.
… We are nervous about the long-term privacy in this space – how do we defend our promise to users to protect them online.
… We feel the need to focus on pragmatic solutions that can be brought to market rapidly, we don’t want to be barrier to innovation – some use cases solved for users quickly while laying groundwork for innovation w/o browser involved.
… PING asked us to present on Tuesday – browsers should be trying to block some of this stuff – freedom of expression / choice – tried to collect some of those arguments in deck w/ PING.
… considering adoping that as work item in WICG – obviously a tension here, we won’t get all of these properties, privacy, security, choice – reasonable balance on space – browser can make risk determiniation – browser can’t read a lot of information – responses are encrypted, don’t want to see that. trust wallet to do something on their behalf.
… we accept that it’s not the browsers role to see visibility into response from wallet.

Brent Zundel: The work is intended to be an item worked on in WICG?

Rick Byers: Yes, have a status on that.
… Where are we right now – we formed a new repo – browser APIs, we can’t even form a charter until we have a solid understanding w/o how things work in practice – trial deployment experience – incubating in WICG – for a while, we had two repos, we agreed w/ apple to merge into single identity credential repo… two explainers – we have a number of things to get through to get to possible API.
… got agreement at TPAC, haven’t made much progress in last six months – started weekly meeting in WICG where we try to reconcile that, scope is trying to narrow down explainer to have consensus on set of goals we’re trying to solve for, what is sketch of API – deployment experience helps us understand what it should look like.
… We have origin trials in Chrome – we have some itnerest in experimenting in Q1 2024 – but that’s a trial, we learn from that, time limited, then turn off and ship something – if all goes well, learn from origin trial 3-6 months, then ship another API in 2024, subject to change.

Sebastian Elfors: Could you please also mail the Android Identity Credential presentation to the W3C VC WG mailing list? (That way it will also reach the persons who are not in the call.).

Brent Zundel: the link to the slides are included in the meeting minutes which will be sent to the list.

Rick Byers: To get a little more concrete, exact shape of API (things could change), we think we want to integrate w/ existing credential manager API – Sam works on FedCM, there are a lot of use cases that might involve multiple sources of credentials – give user choice of verifying age w/ mdoc or VC – trying to integrate into web’s credential management API.
… If you’re asking for identity, important to ask for that…
… you might have list of multiple providers, one could be FedCM – or you could have other holders – format is a string, we’re going to parse it to ensure we understand meaning of request – we will just point to other specs.
… We would like VC example – part of what we’re trying to show is under params, extra params could be arbitrary structured data that flows through to wallet.
… That’s where lots of innovation can happen… but selector is something we have to agree on, information that browser reasons about wrt. risk signal – how can user do this w/ low friction.
… for example, privacy perserving age attestion vs. DL number.
… So this demo is with androind age picker… which calls into wallet in sandbox – wallet gets to see request and see which to send to user.
… What labels are being requested – isolated sandbox so wallet can’t track user, but when individual consents, then wallet is invoked – wallet app opens, confirmation/biomtrics happens.

Manu Sporny: can the browser see inside the wallet?
… what if wallets lie?

Rick Byers: There is a tricky balance here, no we’re not going to try to look inside some wallets, that code is run in mechanism that is sandbox. Our threat model is assuming user has chosen trustworthy wallet so our threat model doesn’t include malicous wallets. Maybe there are legitimate scenarios that wallet matches on every credential. there is some check against that, if people are annoyed by that, they’ll probably uninstall that wallet. Hopefully.

Manu Sporny: that enables wallets that are acting in users interest.

helen: Browser tries to create sandbox that allows wallet to resolve that information in framework so that gets propagated to browser, browser shouldn’t be able to see into wallet contents.

Nick Doty: I don’t understand what the trust model is here… my local government says tey have a wallet, download an app – not sure it’s a choice vs. that’s what I’m supposed to use. Don’t know how much trust user puts in all these pieces. Local government, app store, browser, site –.

helen: Just like Android Play store, if individual installs app – there is also Play Store Policy to review to ensure that wallet app is ok… if we find malicious apps, we could do review of app and kick them out of market.

Kristina Yasuda: yeah basic trust model between issuer-holder-verifier does not change with this API ideally..

Brent Zundel: +1 Kristina.

Rick Byers: The threat model of this API is different from larger threat model – larger conversation is bigger than this API, there are things we can do here… transparency… trust but verify, have browser involved in enabling civil discourse and public tradeoffs. You can have trusted communication w/ Android apps, we already have a model where we don’t have much protection when website is colluding w/ app … we don’t have something to add here wrt. how web-android works today.

Nick Doty: We want to do better than that, collusion might be the most common way this engagement could happen.

Dmitri Zagidulin: oooh ooh, at least we got an easy answer to that first question! :).

Rick Byers: We are committed to doing the work in the WICG, don’t want to exclude mdoc folks, what’s why we chose WICG instead of CCG… where would the proper WG be – narrow down explainer and goals and imagine coming up w/ charter for WG.
… Calls not scheduled yet, start link will take you to github issue – will try to pick meeting soon.
… Tim will try to select meeting place soon.

3. PING Review.

Brent Zundel: We welcome PING to discuss their review and other items as they see fit.

Nick Doty: Happy to talk about review issues:*

Kristina Yasuda: We have certain issues that we’re trying to review and address the horizontal review from PING.

Brent Zundel: https://github.com/w3c/vc-data-model/labels/privacy-needs-resolution.

Michael Jones: The PING request for vc-jose-cose is https://github.com/w3cping/privacy-request/issues/125.

Michael Jones: The related security request is https://github.com/w3c/security-request/issues/60.

Brent Zundel: for visibility and transparency’s sake – we’ve triaged most of these as during CR – we don’t think they’ll result in normative changes to the spec, mostly guidance, do these items require normative changes?
… Is what we’ve come up with amenable – 1271 first.

Nick Doty: Can we talk about process point there? W3C Proces is evolving, my impression is that in typical case all issues in wide review need to be addressed before transition to CR – these things are normative these things are non-normative – all issues need to be addressed.

3.1. Encourage the use of OHTTP (issue vc-data-model#1267)

See github issue vc-data-model#1267.

Brent Zundel: This one is about use of OHTTP in the spec, as of yet, OHTTP isn’t yet finished at IETF, can’t reference it normatively, add encouragement that people make use of it when they can, when they make use of HTTP.

Kristina Yasuda: Similar to brent, we do have concerns about pointing to OHTTP since it’s a draft at IETF… don’t know if it’s mature enough to recommend it – OHTTP should be used once it’s ready, is something like that acceptable?
… What are other WGs doing here?

Nick Doty: Rather than the specifics about OHTTP, it seems like recommendation is identifying when there is a threat about identifying IP address and using privacy preserving proxy, when you do that in a way that you can collude, use privacy preserving proxy… don’t need to make normative reference to OHTTP, you can say when it’s a threat and use privacy preserving proxy.

Kristina Yasuda: that makes more sense.

Manu Sporny: what about a CDN, would that work?

Nick Doty: Usually CDN works on behalf of issuer, so I don’t think we’d say “that gives you privacy” – some resources could be cached in a way that decreases how there is a request back to origin server, but I don’t think we think about CDNs protecting you from colluding from server learning about the request.

Brent Zundel: I think we have enough direction to move forward on this issue… before CR w/o being assigned to it… otherwise, first thing we tackle before meeting again.

3.2. Addressing Verifier Stored Data Vulnerabilities and Legal Compliance (issue vc-data-model#1247)

See github issue vc-data-model#1247.

Brent Zundel: What is the plan for this item moving forward.

Kristina Yasuda: There needs to be a recommendation on how verifier stores/manages user data, we need something around that, something similar – is that sufficient? Doing all we can at technology level, everything else at governance layer.

Nick Doty: I understand that some things have to be enforced elsewhere, is it standardized to communicate that something shouldn’t be stored, or hope that receiver shouldn’t know that things should be stored.

Kristina Yasuda: There are ways to communicate that – intent to retain, but that’s out of scope, we can only talk about data model and how to sign it, we could tell people to use protocols to use those features.

Nick Doty: One of the challenges of having all these different layers/specs – don’t immediately have an idea on flags being needed in data model vs. protocol, where should that flag be? It just seems unlikely that we can expect receiver of the data to know how they should treat the data or user can make decision w/o having some promise about what they’re going to do w/ the data.

Manu Sporny: we have terms of use, but it is set to be deprecated.

Nick Doty: We can’t define how to enforce that in this group, we might want to figure out how to do that.

Dmitri Zagidulin: The thing that comes to mind here is know verifier list – by having to present a trusted UI to the user “so and so company is requesting credentials” – we need “known verifier lists” vs. “known issuer lists” for issuance. The data retention policy can be stated and monitored and legally enforced on that layer. Known verifier lists are coming down the pipeline eventually, something to think about.

3.3. Strengthening Trust Boundaries for Holder Software in Verifiable Credential Processing (issue vc-data-model#1246)

See github issue vc-data-model#1246.

Brent Zundel: This one is tricky w/ nature of charter, not chartered to deal w/ protocols, at same time, wondering what the best path forward is here.

Nick Doty: This is a relevant open question about whether the user by definition trusts the wallet or whether that wallet did something that doesn’t protect their privacy. Again, I don’t know what needs to be defined in which spec. Perhaps it’s a protocol question, but we’re in a situation where it’s not clear – is the wallet acting on behalf of user – or is wallet a piece of software acting on some other entity’s behalf – user needs to protect.

Manu Sporny: themselves from that piece of software.

Nick Doty: That is a question we’re going to have to answer, don’t know if it needs to be in this spec or not, which party is user agent.

Dmitri Zagidulin: From phrasing of the comment, that last sentence is to highlight trust boundary, would it be sufficient to highlight the trust boundary – wallet is in position of power, it is a user agent, it should be treated as such?

Kristina Yasuda: I do think we can address that, it’s in scope, users are not directly tied to software they’re using – don’t know if we should introduce term wallet, but adding a few sentences here should be appropriate.

Dmitri Zagidulin: do we actually use the term ‘holder software’?

Dmitri Zagidulin: (I know we have ‘holder’).

Brent Zundel: I don’t believe we do.

Joe Andrieu: Our presumption is wallet is user agent, but people will need to use wallets under control of other entities, when you’re acting on behalf of us, having understanding of trust boundaries allows one to understand risks when using technology.

Nick Doty: +1 Joe.

Brent Zundel: We could add some guidance, but at this layer there’s not much we can do what we can enable/enforce.

Manu Sporny: We do have privacy/security considerations, we can state things in there.

3.4. Mitigating Location Correlation via Common Issuers (issue vc-data-model#1245)

See github issue vc-data-model#1245.

Brent Zundel: Gabe can you let us know if you’re ready to move forward on this?

Gabe Cohen: Issuers being considerate of information they’re disclosing… can do PR soon.

Nick Doty: Just to clarify this, in some models, privacy pass – separate attester and issuer, attester is doing detailed subject matter evaluation, pass on fact of user w/o passing information on – if I pass on single claim from DL, you get claim and details about who signed it – which authority issued the DL.
… Who issued is more substantial than piece of information I’m revealing, user has asked for age – and actually what is being rquested is not age, but what is sent i who government authority is.

Kristina Yasuda: this is what we wrote for SD-JWT: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-05#name-issuer-identifier.

Kristina Yasuda: on the issuer identifier.

Manu Sporny: There are systems that exist, that takes in a identifying VC that translates to a privacy preserving VC, then uses the privacy-preserving VC.

Gabe Cohen: there is a section https://w3c.github.io/vc-data-model/#issuer-cooperation-impacts-on-privacy.

Brent Zundel: Yes, Gen is working on similar model, we can translate one VC to another to create that privacy preserving thing such as what TruAge does. Their trust in the system is what enables it to work. I do think that we need to, if we haven’t already, note that trusting issuer can reveal thing sabout it, additional information there could help.

Gabe Cohen: I’ll add more details in that section.

Brent Zundel: If there are no other comments on this issue, w/ VC data model, moving on to other items.

3.5. Address Metadata-Driven Correlation (issue vc-data-model#1244)

See github issue vc-data-model#1244.

Brent Zundel: This is another type of variation on previous issue… don’t know if path forward on this is much different from what we just talked about. Happy to hear thoughts from group on this item.

Nick Doty: When we have non-essential properties that can vary, if we have recommended set of thoe properties, everyone can follow them, users can be in single anonymity set – do you need variation in these things, or can there be recommendation of “everyonen that does credential in this style, use these parameters”?

Kristina Yasuda: Yes, not sure I agree, don’t know how realistic this is – even if federated identity, information about user can be in SAML assertion, and each representation can be a standard, but we can’t force everyone to use same VC to do the same thing – unfortunately, there are disputes on how to express credential at multiple levels – how is plain text about user claims being represented, what cryptsuites are used, at every level there are almost religious debates on what the best way to do this, don’t want to touch this.

Brent Zundel: With the VC model, and notion of selective disclosure on presentation, every issued VC is ideally following – for example DL, on issuance side, we have commonality on structure and data provided. Requring presentation of subset of credential even on metadata part of it other than few that we’ve already agreed to. I’m not sure what we can do about this issue.

Manu Sporny: this one’s tricky. I think what Nick is asking for: ina perfect world we could establish best practices for certain credentials. e.g., an age verification credential should have a correlatable issuer and should only express a large bucket age range.
… and the WG could work to create an age-verification credential template with that information. We’re not chartered for that yet, so we will need to use security and privacy condsiderations sections. We do have a sections that strongly encourages data minimization, i.e., selective disclosure.

Joe Andrieu: The model for validation in VCs does require issuer to be correlatable to see if particular identifier is someone they should trust – if I want to see if someone can drive, I can’t take self-issued VC – that’s something that’s baked into the model, we can’t get past that part of correlation.

Nick Doty: This is helpful, the verifier only has some list of people that they trust in order for system to be functional, understood.

Joe Andrieu: +1 to group mechanisms to mitigate correlation of issuers.

Nick Doty: We can say if you can “group” that trust in some way, that can help user in some way – so issuer corelation dosn’t happen. About formats, if you’re going to try to group issuers, you could group these other things – that should be the recommendation, grouup issuers, but also focus on grouping attributes – unify formats so you can’t track it back to original issuer.

Kristina Yasuda: what we have put in SD-JWT and have received positive feedback “To mitigate this issue, a group of issuers may elect to use a common Issuer identifier.”.

Brent Zundel: that’s helpful, we have good path forward.

Kristina Yasuda: We’ve written something similar for SD-JWT, but can’t do that tomorrow, can eventually do that.

Brent Zundel: ok, assigning kristina.

3.6. VC Jose-Cose.

Brent Zundel: Ok, let’s look at vc-jose-cose and time box for status list.

Michael Jones: The privacy and security self-review for vc-jose-cose is at https://github.com/w3c/vc-jose-cose/issues/93#issuecomment-1720985793.

Michael Jones: It contains references to the requests for review to PING.

Michael Jones: There are comments to PING requests, we haven’t heard back from them, but we’ve done process action to move this forward.

3.7. VC status list.

Kristina Yasuda: here is the self-review from status list: https://github.com/w3c/vc-status-list-2021/issues/77.

Nick Doty: privacy review request is only an hour old, so hasn’t been completed yet :).

Manu Sporny: Group discusses status list PING review use case.

3.8. Add privacy considerations for multi-bit correlation (issue vc-status-list-2021#86)

See github issue vc-status-list-2021#86.

Manu Sporny: this issue concerns our credential revocation mechanism called a status list. It started out as a big bit string, each bit represented a single credential. If there were 100,000 credentials in the list, then that’s your herd size. These are public on the web.
… if an adversary looks at the string of bits, they can’t link this to the original credential, so along with a big enough herd size this is okay. We are going to encourage adding noise so that things are obscured further.
… as of a couple of months ago, multiple different statuses for a single credential are possible, so multiple bits for same credential. The example there is a shipping container that may have multiple status values defined by the issuer. The concern is that by having multiple status values you may be reducing the size of the herd.
… Not sure what the general question is. There is an assertion that adding more bits about each credential in the list, then correlation becomes easier. Adding randomized data may be more difficult, etc.
… looking for general guidance from PING on this approach and any concerns there.

Kristina Yasuda: whether there are 1bit per credential or 3bits per credential in the bitmap does not help the verifier to correlate any better.

Nick Doty: Revocation problem is something we see in other areas, it’s a common privacy issue for person checking being revoked – verifier that’s checking if something is revoked – one concern is you want this to be consistent, issuer gives out credential, check the list and one problem you’re having is you want issuer saying list is same for all credentials, not unique URL – that’s a tracking issue – single credential can be tracked (which is not good).
… That is a common problem on the Web, some IETF work going on on consistency of resources, increasing number of things that website providing information can provide key – provides same information to everyone, different keys, different lists won’t become uniquely identified – can we use similar mechanisms for something like this, so issuer is giving out consistent list URL.
… Don’t know, perhaps don’t understand why revocation is in a public list?

Brent Zundel: The reason that it’s public is so that there is less visibility on who is requesting it – issuer hosts the list, gets less of an idea of where the lists are being used.

Nick Doty: Is goal to ensure verifier to know after the fact if something got revoked?

Brent Zundel: It would enable revocation/status changes to occur after issuance of credenial, reduce visibilty on where credntial goes – enables verifier to get up to date status by querying momst current version of the list.

Nick Doty: i’s not just at presentation time…. if I ever signed in w/ DL, at any future time they’ll know if DL gets suspended?

Brent Zundel: That is correct.

Nick Doty: That seems scary to me.

Kevin Dean: +1 to scary.

Brent Zundel: agree with the scary.

Nick Doty: That doesn’t seem like a goal, when I present my credential to an RP, they want to know it’s valid, also they get to subscribe to changes to my DL?

Kristina Yasuda: status list can be avoided with short lived creds but that kind of undermines the point of three party model.

Joe Andrieu: Manu said close to what I said – you could provide proof of status, I don’t think we handle that well – conceptually, you could do that – valid status you could check, but we haven’t teased that out yet.

3.9. PING Discussion Closure.

Brent Zundel: anything else for us before we break?

Nick Doty: Thanks for having me – apologies for not coordinating better – we are in situation where some privacy quetions are ecosystem wide, hard for any particular spec to answer it, but since they are going to increasingly occur, useful to us to work at an ecosystem level, who is being trusted where, where might privacy issues arise, so no individual spec author has to answer those questions. Perhaps we can work on it in this group or PING or overview.

Manu Sporny: document somewhere so people can more easily reason about where privacy / security concerns arise.

Kristina Yasuda: There is trust model analysis going on, still in draft, still looking for input.

Kristina Yasuda: here is the trust/security that was the basis of a formal analysis: https://vcstuff.github.io/oid4vc-security-and-trust/draft-oid4vc-security-and-trust.html.

Dmitri Zagidulin: wait when’s next break end?

Kristina Yasuda: the formal analysis will be published soon too.

Ted Thibodeau Jr.: dmitriz – ~84 minutes from now.

4. CR status.

4.1. VCDM.

Brent Zundel: core data model as 23 open issued labeled “before_cr”. 5 labeled ready for PR. 18 that needs PRs.

Andres Uribe: A handy link: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Abefore-CR+-label%3A%22ready+for+PR%22+-label%3A%22pr+exists%22.

y-sakuma: y-sakuma has joined #vcwg.

Brent Zundel: correction 9 have PR exist so there are only 9 that need resolution.
… anticipate that candidate recommendation is likely to take a while. 28 days is the minimum.
… we will be fortunate to find time for 2 CRs. If we don’t go soon, we may not have time for more than one.

Ted Thibodeau Jr.: https://w3c.github.io/spec-releases/milestones/.

Brent Zundel: ideal route is to have PR in by may. Working backwards, we need to be in CR now. Concern about 9 open issues.
… goal of the session is, “What is the CR plan for each of these documents”.

Manu Sporny: there is an expectation that all horizontal review comments are addressed before CR. Checked process and that does not seem to be the case. All comments in issue tracker don’t fall into that category. nothing in the process says that that work needs to be done before CR.
… an acknowledgement of Nicks assertions and we ended up re-categorizing issues as before CR when we didn’t need to.
… though there are 9 items here, some are horizontal tracking issues. If we have people raise PR on these issues it should be easy to transition into CR by October.
… already have a test suite for it that exists with tests for all normative statements except for ones in the last few months.
… modifications this time around are not that heavy and we have a test suite with a variety of tests in there already. Timeline looks realistic.

Brent Zundel: For the core data model, is it a reasonable expectation for for all ready-for-pr issues to have PRs in for review week of 25 sept.

Manu Sporny: For ones assigned to me, yes. can’t speak for others. Imagine for a lot of these is possible to have a PR in. The language one needs to get discussed as a group. The related resource one needs to be discussed as a group.

Brent Zundel: At what point should we look at an issue and say we don’t have time. I’m feeling like my definition of too late is earlier than others. Wants to have confidence and a plan in place to deal with lingering issues.

Andres Uribe: For clarification, there is a risk that if we don’t get through these when we go to CR, that might increase chances to repeat CR.

Brent Zundel: as to which issues pose the most risk, I can’t say.

Ivan Herman: As an example, Issue 870 is marked as pre-CR and open since Feb 2022. So far we are unable to find a consensus. Can we accept that we cannot find a consensus and close it? I remember this one, but there may be more.

Manu Sporny: by the second week of October, we can close the door and say that is it and leave remaining issues to be delayed to a future group. 870 feels medium risk to me. Related resource feels high risk. String value in Jose fields seems high risk. Everything else feels addressable or non normative guidance.

Brent Zundel: Agree with almost everything except 870 which I consider high risk if we don’t solve it in a way that appeals to reviewers.

Manu Sporny: Meaning the only resolution is to remove from the spec and add it as a reserved or deprecated term.

Brent Zundel: That is my preference. Either something normative or not be in the spec as a reserved term.

Dmitri Zagidulin: We have addressed all the comments in 870 except the completely different issue which is range and domain for the vocabulary. We can in good conscience move these to a separate issue and close this one.

Ivan Herman: Removing the domain for the evidence property is easy to do, but I am not sure that there is consensus to close the issue if that is done.

Dmitri Zagidulin: the consensus on the domain/range issue is a completely different matter though.

Dmitri Zagidulin: can we at /least/ split it out to its own issue?

Manu Sporny: 1EdTech (sp) in a normative specification they publish use the evidence field. Can we site that as a concrete usage of the property by another standards settings group.
… to elaborate. We already have demonstration of 2 specification that use this property as an extension point. Is that enough?

Dmitri Zagidulin: question for manu. The matter of evidence has been resolved. What remains is a completely different issue.

Brent Zundel: What 870 has come to represent is the existence of the evidence extension in the spec and what we are going to do with it despite how this issue began.
… if the group is comfortable saying that one way to do this is by using the education spec, then in my opinion we can keep the property in the spec.

Manu Sporny: We define it in the core spec, and here is an example of another standardization body using it: https://www.imsglobal.org/spec/ob/v3p0#evidence.

Brent Zundel: I am afraid its too late, if PRs are not submitted by the 2nd week of October then we have to drop these.

David Chadwick: I believe the education group has set the type and id field wrong. They have the type as a set.

Dmitri Zagidulin: type can always be a set…

Brent Zundel: This is another indication that we dont have consensus to point to this spec.

Manu Sporny: some people who raise these issues might get upset, but we can proceed as stated. We can discuss the ed spec usage in the issue.

Kristina Yasuda: back to point on horizontal review issue. Chairs already told Nick to address these before CR. My interpretation of the review process is that these issues are addressed before CR. The current plan is to address the normative and non-normative horizontal review comments before CR.

Brent Zundel: is there more before-cr issues to discuss, if not we will move on to the other specs.

Manu Sporny: concerns about the plan as a change to the goalpost. The resolution should hold. Can we keep the resolution, make the PRs as fast as we can.

Kristina Yasuda: chairs will talk and report on the mailing list.

Manu Sporny: Having just read it I disagree with the interpretation of the process.

Gabe Cohen: are the issues that we discussed for the privacy review still urgent to complete.

Brent Zundel: yes.

4.2. vc jose-cose.

Brent Zundel: move to vc-jose-cose and get a sense of what it takes to get that to CR.

Michael Jones: we don’t have all that many issues or PRs without agreement. One is ready to merge after it ages out for a week. The big rock is to add DID support to the specification.
… have not had a conversation with orie about possible next steps. We can look at issues and see if there are people assigned to all of them.

Brent Zundel: not sure if that is the best use of time right now. vc jose cose editors should get together and review the discussion of this week. Is it reasonable to have a CR plan presented by the editors in two weeks.tors.

Michael Jones: yes. I can get together with orie and write things up.

4.3. vc status list.

Manu Sporny: VC status list still has a large number of issues. But given progress during TPAC, I think we got the biggest concerns addressed. That should make the remaining PRs easier. Its not realistic to go into CR before end of October, mid-November.
… as far as test suite is concerned, we had a test suite for single-bit status list, but now that we are doing a combined approach, the test suite will have to be re-written. This could potentially happen in parallel.

Brent Zundel: co-chair has noted that getting to a first CR as quickly as is reasonably done anticipating that a second CR is needed. Rather than hurrying into a CR, the editors could have a plan in place that demonstrates the could have a single CR. Dont think that could happen for the core data model.

Brent Zundel: that is my fear.

4.4. General CR scheduling issues.

Ivan Herman: “second CR” may be misleading for folks that don’t understand all the details. We enter CR with one document. There are two possibilities. We can update the CR Draft. This is something we can do as easy as we do with the working draft. We can issues new CR snapshots, as many as we want, as often as we want, and that is not a huge deal. Except that is has to go through a slower publication mechanism (through me).
… the only big difference is that the snapshot is issued when there is a major technical change that invalidates earlier test. Would not overestimate the weight of publishing additional CRs once we enter CR.
… small, non normative, editorial changes that do not jeopardize testing can be done easily.

Brent Zundel: each snapshop does require a minimum 28 day period. Meaning we can only do one every 28 days.

Ivan Herman: correct.

Manu Sporny: keep in mind that we have CR drafts as soon as something merges to main. CRDs we can iterate quickly.

Ivan Herman: that is echidna.

Manu Sporny: once we are in CR we can iterate rapidly. We don’t need to waste a CR snapshot for each change. We can pile them up until we feel strongly that we have what we need and are confident.

Brent Zundel: to add nuance. Yes, we can introduce drafts rapidly and produce a snapshot when ready. but when making these changes we will need another snapshot.

Ivan Herman: to give an example, we accumulated lots of change and when we want to go to PR we issue a snapshot 1 month before.

Ted Thibodeau Jr.: the changes that we make to the CR draft do not have to be published to CR. Best if we did, but there is nothing that mandates that we must. the CR snapshot does not open a door for 28 in which we cannot publish another. It restarts the clock.

Brent Zundel: I was told this was frowned upon.

Manu Sporny: everyone want to finish on time or under time. If we get to CR and are seeing multiple implementations and progress, charter extensions are usually granted. I have not seen one declined in this instance.

Brent Zundel: for the core data model, we know the scope and have a plan. For jose-cose we are going to hear from the chairs by the next meeting. We heard VC status list is on track with more of plan laid out in the weeks ahead. Chairs need to consult regarding resolutions for data-integrity and how they are impacted by the knowledge we have for expectations for horizontal reviews.

5. test suites.

6. vcdm + di.

Brent Zundel: every spec we bring to req track needs a test suite. Would like group to be aware of the plans for test suite.

Manu Sporny: data model 2.0 data-integrity ecdsa and ecdsa all use the same test framework. All have multiple implementers.
… plans to add docker support but we have to prioritize what we are implementing. Priorities are test coverage. one we have that, implement extra features such as supporting vc-jose-cose output format. I don’t know if there are plans for cose signing. we can add support for that so we can extract the payload and test against vcdm 2.0. Work with game on docker support. questions?

Brent Zundel: how are data integrity and vcdm test suited incorporated or not. When you test data integrity are you also testing the core data model.

Manu Sporny: you make a call to a system and send it a payload which is a vcdm payload where you ask it to secure something and you get one back. Assumption is that the signer will do the tests in the vcdm. vcdm 2.0 test suite is supposed to be agnostic to the securing format. For data-itegrity test suite they care about the securing formats. Does that answer your question?

Andres Uribe: what does the process look like to go from spec to test case. Is that manual or automated.

Manu Sporny: its a manual process. There are tools to extract normative statements, but they are not perfect.

6.1. vc json schema.

Gabe Cohen: currently there is an implementation somewhat like the test suites manu mentioned. But you have to implement a CLI in the docker container. This CLI can call through to your server or API. There is a set of tests, one for each normative statement, with a manual mapping.
… I think its fairly straightforward and happy to work with manu on other test suites to align. Shopping around for folks with implementations to add to the test suite.

Manu Sporny: +1 happy to work w/ decentralgabe on aligning how these things function, especially pulling their docker stuff in, if possible.

Brent Zundel: Do you know of other implementations aside from blocks’.

Gabe Cohen: transmute has one but have not written an implementation for the test suite. they will not implement both types. Looking for someone to implement both types.

6.2. vc jose cose.

Michael Jones: orie has code, but I don’t know what it does and doesn’t do.

Brent Zundel: can you make this part of the CR plan.

Michael Jones: yes.

Manu Sporny: Looked through the test suite and have concerns that it does not test the normative specifications. It has vectors but that not how test suites for W3C specification work. Add this to the list of things to discuss.

Michael Jones: understood.

Kristina Yasuda: I don’t think the test are done yet.

Michael Jones: any W3C process or guidance on the way these tests need to be factored?

Ivan Herman: no.

Kristina Yasuda: minimum, all the normative requirements must be tested. How they are tested is not specific.

Brent Zundel: features must be tested, not necessarily normative statements, but all statements must be covered.

Ivan Herman: one possible organization of the testing is to start with the must statements and do one test for each. Its also OK to do a test that covers more than one must statement. There is no one-to-one requirement. However, if the second option is used, it must be documented.

Manu Sporny: note that the second approach can be painful because if someone fails one part but not another it creates arguments. advice.

Brent Zundel: is there any other conversation about vc-jose-cose test suites to have.

Michael Jones: not that I am aware of at this time.

7. Chain of GS1 credentials to identify a trade item (issue vc-use-cases#146)

See github issue vc-use-cases#146.

Joe Andrieu: we have a new focal use case contributed by Kevin.

Kevin Dean: the use case GS1 put together focuses on the GS1 identification system. For those that are not, we are the barcode people. That numbering system is managed by GS1. There are a number of other supply chain standards for master data, supply chain data, traceability, and so one.
… as part of our credentials in GS1 is a chain of credentials. GS1 grew up in the non connected era in 1970s. The system had to be developed to support unique identification without connectivity.
… the core identification is managed in Brussels and then delegated to organizations around the world.
… For example global delegates a number range to GS1 Canada, which delegates a subset to a company.
… We end up with globally unique ID for trade items because the ranges issues are unique within the scope of the issuer of that range.
… in order for the identifier to be valid, that chain of ranges must be valid. There are rare circumstances that companies go out of business and their right to issues identifiers from the range is revoked.
… a chain of GS1 credentials to identify a trade item. Also applies to anything else that uses a GS1 identifier, but we focus on a trade item as its the most common use of identifiers.
… this use case has been provided by GS1 and we are happy to have our name there.
… the use case addresses mergers and acquisitions. Its important that the GS1 license of the acquired company transfers ownership to the aquiring company. This doesn’t invalidate any of the credentials generated previously.
… this is because they were created at the time when the license was valid.
… to break this down we consider the actors in the document. GS1 prefix is issued to the member organization (country). The GS1 company prefix is issues from a member organization to a member company (example company).
… holders are typically the subject but could be other entities. In some cases large CPG companies have a separate company that manages digital assets including company prefixes.
… the verifier is any trading partner that needs to validate the license.
… the GS1 prefix license is valid if issue by global office. the GS1 company prefix credential is valid if it points to a prefix license credential. The GS1 GTIN/key credential is valid if it points to a valid company prefix crednential.
… examples are provided in the document.
… a more complete description is in a whitepaper on the website. These are still in proof of concept but are in use by other organization in their own proof of concepts.

Manu Sporny: are there thoughts you have on upgrading to the VC 2.0 data model. We have things like related resource that might modify the way you are modeling data.

Kevin Dean: Its a priority item but it a question of resources.

Manu Sporny: same for credential status.

Kevin Dean: there is. Credential status is one of the things we are really interested in. Its more than just revocation and suspension>.
… we will not put an expiry date into the credential as some companies maintain these licenses indefinitely.
… we need some way of saying that this credential has been transfered. There is a new credential that replaces this credential. That may require following multiple validation paths.

Michael Jones: Sounds like an HTTP 301 Moved Permanently redirect!

Kevin Dean: GS1 credentials are public, but its up to member companies whether they make their credentials public or not.

Manu Sporny: is that captured in the use case?

Kevin Dean: We do talk about the transfer of license credentials.

Paul Dietrich: https://github.com/gs1us-technology.

Paul Dietrich: Just a quick plug – if you go to GS1 US Github page, you’ll see two libraries, based on open source library from Digital Bazaar – the other library applies business rules.
… We’re starting to roll this stuff up into code – read from programmers point of view to see how it works.

Kevin Dean: https://ref.gs1.org/gs1/vc/data-model/.

7.1. other items on use cases.

Joe Andrieu: put out a call for contributions. Wants examples of usage, name, url. don’t want to endorse, just show VCs that are used in production or prototype.

Brent Zundel: do you prefer this in an issue or directly.

Joe Andrieu: issue, please.

Brent Zundel: Last topic is the GSMA liason statement. Announcement before a break.

8. GSMA Liaison statement.

Kristina Yasuda: We have received a liaison statement from GSMA which will be discussing.
… Our data integrity BBS work is interesting to GSMA. This liaison statement is a request to coordinate work between our working group and GSMA.
… One of the implications would be nominating contacts for the coordination.

Brent Zundel: We already have existing relationships with organisations such as ITU. In practice, this GSMA relationship could result in more reviews for our specifications.

Joe Andrieu: who do we reach out to?

Brent Zundel: The chairs and staff contacts have that information.

Manu Sporny: They are being pretty direct and asking specific question. I would expect that the GSMA would put forward invited experts. They are no longer a W3C member, which might complicate their involvement.

Kristina Yasuda: yes, GSMA will need to have an official venue to participate.

Manu Sporny: I don’t know whether we need to respond before the liaison is set up. Ivan, what’s the process here?

Ivan Herman: We set up the liaison first.
… Brent should respond on behalf of the WG to the email.

Manu Sporny: Thank you to the Chairs for chairing and staff for staffing! Thank you Brent, Kristina, Ivan!

Manu Sporny: Thanks all! :).

9. Resolutions