Adopt and publish StatusList2021 as an credentialStatus extension

[msporny]

During the 2022-11-09 telecon, it was suggested that we need to reference a concrete extension specification for the credentialStatus property. It was suggested that we do the following things:

1. Adopt the Status List 2021 specification from the Credentials Community Group as the first of many potential status list specifications (without preferring it over another status list mechanism).
2. Publish that specification as an Editor's Draft in the VCWG.
3. Work toward publishing it as a First Public Working Draft over the next couple of months.
4. At some point in the future, add the StatusList2021 extension to the VC Extensions Registry.

There seemed to be support for this approach with no objections registered on the call. This issue is to see if we have consensus to do this and on what timeframe.

[David-Chadwick]

The current practice appears to be for short lived un-revocable credentials that the credentialStatus property is absent from the VC. The verifier therefore has to assume that the VC wont be revoked. So should we also define a value for credentialStatus that states 'this credential will never be revoked' so that the verifier is not left guessing about the credentialStatus when there is no credentialStatus property present in the VC.

[David-Chadwick]

At the VC WG meeting on 7 Dec it was noted that credentialStatusList2021 could apply to the credential (e.g. degree certificate) or could apply to the proof property (e.g. private key compromised), through the statusPurpose field. However, the current values that are defined for this field do not differentiate between these two purposes. Thus the statusPurpose field should have more clearly defined values for it that more precisely indicate its purpose.

[msporny]

However, the current values that are defined for this field do not differentiate between these two purposes.

Yes, correct, any new status purposes will have to be defined/added. This is fairly trivial to do given that it's just a simple text string. It's even possible to define a new string and not register it in the spec. The spec defines a few values for statusPurpose, but doesn't define all of them.

In any case, fairly trivial to add more statusPurposes if the group needs to do that.

[iherman]

The issue was discussed in a meeting on 2022-12-07

• no resolutions were taken

View the transcript

2.1. Adopt and publish StatusList2021 as an credentialStatus extension (issue vc-data-model#974)

See github issue vc-data-model#974.

Brent Zundel: move to remaining topic. StatusList2020. have an issue open ^.

Manu Sporny: providing background. the VCDM has a property called 'credentialStatus' purpose is to tell you what the status of the credential is -- revoked, suspended, something else. this mechanism allows an issuer to issue a cred and still have the ability to say the credential is still valid or no longer valid.
… can think of something like an employeeId credential, issued to an employee - they have it in their mobile phone, at some point they change jobs away from that employer. the issuer then revokes the credential saying 'they are no longer at the company'.

Manu Sporny: Status List 2021: https://w3c-ccg.github.io/vc-status-list-2021/.

Manu Sporny: we did not define a concrete representation to do this in v1 of the work. there is an item VCStatusList2021 incubated in the CCG link in chat. a number of implementations. people seem to be OK with the latest version of it. we do not expect drastic changes to the spec at this point. there is a test suite for the spec..
… this issue suggests adopting the status list 2021 from the CCG. suggested a month ago, more depth today.

Brent Zundel: properties in the VCDM that do not have a normative way to fulfill. do not love statuslist2020, but it is fine. people feel similarly. solid and basic way of providing what a credential status is. char hat off -- in full support of us considering this as a work item. chair hat on -- point of this is to decide whether it is a work item.
… what do you think about bringing it in, or what that means?.

Dave Longley: just to be clear, the issue says "StatusList2021" (not 2020).

Michael Prorock: I am in the "it's fine" camp, it's not ideal. have not seen anything practical, better, more widely deployed, tested. natural if we are going to bring in a status list ... this is what 2021 enables. i have to reiterate my hatred for dates in titles.

Manu Sporny: Link to current test suite: https://w3c-ccg.github.io/status-list-2021-test-suite/.

Brent Zundel: apologies, it is StatusList2021.

Orie Steele: #1 - we have to define at least one of these things to keep the credential status property in the data model. been said, but it's important. have a number of concerns with this work item. have not seen a version that supports vc-jwt or other security assertion formats.
… this item like so many other items, assumes a core data that is subject to dispute. not appropriate to bring it in at this time. expands the scope of the group, new work. not sure how to resolve issues with this suite if @context being optional is handled in a different manner. appreciate Manu's comment, but do not feel comfortable until it's resolved.

Manu Sporny: supportive of what Orie said. want to roll back to "it's fine but not great." everyone is lukewarm about it. we want a more aggressive privacy option. been viewed as 'adequate' not amazing. effectively good enough..

Dave Longley: +1 to StatusList2021 being "adequate, but not great" :).

Manu Sporny: we could do better in the future if we were willing to do more advanced crypto. people have not reacted violently against 2021's herd privacy approach. just ok - but that's fine.

Gabe Cohen: I just wanted to respond to Orie's comment, we do have an implementation that works w/ VC-JWT and I can add an example to existing draft if that's helpful..

David Chadwick: coming back to the point last time i spoke. big issue about the data model. credentialStatus should not be a part of the data model, because it's bound to a proof. cannot have it bound...the status should be a part of the proof and not bound to the core data model.

Brent Zundel: the work is there for us to do regardless of whether we bring it in now. up to the working group whether we bring it in now. not bringing it in now doesn't mean it's not there for us to do.

Manu Sporny: to respond to DavidC: no it has nothing to do with the proof. it makes more sense...credentialStatus has to do with the credential itself, not about the proof. it is about the fact that you are issued a uni diploma, and whether it is valid or not, regardless of cryptographic protection on any of the data. business rules, not cryptography.

Dave Longley: +1 to manu.

Orie Steele: agree current interpretation is consistent with what Manu said. DavidC may be onto something. if not to be handled as business validation logic, could be handled as part of the proof. could be relevant to the proof section, not credential metadata. comes back to "what is the core data model" do we have a clear understanding of the differences b/w these things..
… current StatusList2021 - it is a property of the credential. after credential verification of the status list, a verifier can dereference and do checking. it is a business process the verifier could ignore (e.g. check signature, not status)..

Dave Longley: seems the question is: "are you revoking a digital signature ... or a credential?" (or could there be both of these things? and is that too complicated?).

Dave Longley: +1 to Orie where credential status is handled the same regardless of securing format.

Manu Sporny: +1.

Orie Steele: if checking the proof/status is a part of the verification process. in Jose/cose use the crit header. ... how are we going to address these scenarios if we have more than 1 core data model or security format? want credential status checking to be handled consistently. data integrity proofs and jose/cose formats around the same core data model. not clear the best path for the item.

Joe Andrieu: want to elevate DavidC's point to a conversation we haven't fully engaged with yet. What is a "Credential" vs "Verifiable Credential." we have a disconnect. my sense - a credential without a proof is a "credential" it is in json and maybe a proto-vc. with a proof it's a verifiable credential. there's another thing in the real world called credentials that people use VCs to represent (e.g. a bachelors degree).

Orie Steele: +1 Joe.

Dave Longley: +1 to Joe.

Joe Andrieu: has nothing to with a VC. there is a weird semantic disconnect. don't know where we should come down. in the JFF plugfest, people created the id of the cred as the real id, not the id of the digital object.

Brent Zundel: to StatusList2021 - we can decide the direction if we bring it in as a work item.

Manu Sporny: yes, it's different in VCs -- VCs aren't x509s ....

David Chadwick: thanks Manu for point of CredStatus could be the status of the degree. want to point out in x509, revocation is entirely with the digital signed cert. says we need to have 2 different representations (David Longley hinted in chat). still needs to be a cryptographic revocation list, e.g. if a university lost its private key the cred could still be valid. need two separate revocation mechanisms.

Phillip Long: from the edu perspective Joe described. in edu, has never been an opportunity for a cred to be shared with anybody at all. if it is an "official credential." the only source of truth has been the institution itself/registrar. any time anyone has a presentation about their degree or transcript to a 3rd party it needs to come from the institution/registrar, since they're the only one's considered author.

Gabe Cohen: itative.

David Chadwick: @manu it could if there is flag to say which revocation it is referring to.

Manu Sporny: That flag already exists, DavidC :).

David Chadwick: @manu. Excellent!!.

Manu Sporny: It's called "statusPurpose" -- https://w3c-ccg.github.io/vc-status-list-2021/#statuslist2021entry.

Phillip Long: credentials are making this tamper evident, which allows this interaction to change. conversation with national student clearing house. they agreed to put a signature on a degree VC which is a 'sufficient verification of truth' and does not need to come from an institution itself. distinction is important - verifiable means you can hand it to a 3rd party. treated as authentic and original.

Manu Sporny: To be clear, I disagree that this is something that should exist in the proof, but we can have that discussion later :).

Manu Sporny: responding to DavidC question about cred or proof. StatusList2021 is agnostic to where it is placed. just a status list. could be about a credential, proof, sheep. doesn't matter where it shows up. it is just a bit field and you flip bits. though, I disagree you should put this in proof metadata. if the group wants to do this, it can serve both purposes.

Brent Zundel: is the work item in the scope of the charter? is it supported by at least 3 participants from different organizations? yet to poll. should we adopt it? does not require strong consensus. will not be taking a proposal today to bring it in as a work item. may do so during the next call. any other questions/comments/concerns?.

Orie Steele: we ran a proposal to adopt ecdsasignature2020 a week ago, did we follow the process then?.

Brent Zundel: 2 weeks ago. in response to the resulting conversation about that work item. resulting in the chairs establishing this process. the process just mentioned did not exist during that conversation. it came into being as a result.

Ted Thibodeau Jr.: no strong feelings on the work item. probably should be taken up. something like it will be necessary. another one will serve roughly the same purpose and we'll have to do it. abundantly clear to me and the people in this group that we have some glaring issues with the existing data model and what is really going on.
… as we were discussing a few weeks ago re: validFrom/until attributes, we have 4 dates instead of 2, but may be 6 or 8. tracks with crypto/payload validity. don't have a strong enough picture in my head to go down the list.
… brief back and forth with DavidC. basic stick figure diagrams of the cred metadata, the Credential, the proof, proof metadata. not the only 4 we need to talk about. need to spend some focused time on that. could be a zoom whiteboard or F2F - open to ideas. sooner we do it the better off everyone will be. the result will be breaking changes.

[David-Chadwick]

I am not just talking about adding new purposes, which as you say can be easily done, but I am also suggesting changing the definitions of the existing purposes to be more precise. Do you see the current definitions being set in concrete?

[msporny]

I am not just talking about adding new purposes, which as you say can be easily done, but I am also suggesting changing the definitions of the existing purposes to be more precise. Do you see the current definitions being set in concrete?

No, I don't think the current definitions are in concrete -- we have the latitude to make them more precise.

I will note that this specification is probably going to ossify quickly in 2023 as it is deployed into production programs... so, if we want changes, we'll need to focus those changes into Q1 2023 at the latest.

[brentzundel]

https://www.w3.org/2017/vc/WG/Meetings/Minutes/2022-12-14-vcwg#res

[msporny]

The transition of StatusList2021 from the CCG to the VCWG was approved on 2023-01-03: https://lists.w3.org/Archives/Public/public-credentials/2023Jan/0003.html

The next steps are to transfer the repository to the W3C VCWG from the W3C CCG.

@iherman, you have been added as an admin on the repository, please transfer it when you're ready: https://github.com/w3c-ccg/vc-status-list-2021/settings

[iherman]

@msporny the repo has been transferred. Also

• I have updated the w3c.json file accordingly
• Have added, to the access list, the same groups (with the same rights) as for the data model repo, and added you as an admin
• I have modified the pointer to the document in the README file of the repo, but that file would need more care. I leave that to you.

[msporny]

The spec has been updated to note W3C VCWG authority over the specification and Editor's Draft status here:

https://w3c.github.io/vc-status-list-2021/

This issue is now resolved, closing.