Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Context about how this differs from 2020-rl #3

Closed
swcurran opened this issue Apr 6, 2021 · 23 comments
Closed

Context about how this differs from 2020-rl #3

swcurran opened this issue Apr 6, 2021 · 23 comments

Comments

@swcurran
Copy link

swcurran commented Apr 6, 2021

It would be very helpful if the specification referenced the vc-revocation-list-2020 and defined the differences between the two. I've been trying to scan to figure out the differences, and from what I can see a couple of mentions (and an example) of "SuspensionList" is the only change. Is that correct?

A related question is whether the VC for the list have a type that MUST be "RevocationList2021" as stated, or would it also allow "SuspensionList2021" to align with the addition of allowing SuspensionList in the VC given to the holder?

If that is the case, I would add my name to the question in #2 asking why not add a "call it whatever you want" listtype field so you aren't limited to revoke and suspend.

Thanks!
@csuwildcat
Copy link

This is the direction I would hope to go - just allow a field like topic where the status topic can be whatever the list implementer wants (possibly with a registry of known values and their meanings).

@csuwildcat
Copy link

@msporny as we begin implementing this in our production stuff, we would really like to see the concept of topic/list-type. This is important because what we really want is to have all the lists be StatusList2021, but have that status topic be different depending on the need/goal. The concept of a topic/list-type would make that easier, imo.

@kezike
Copy link

kezike commented Aug 5, 2021

Agreed with the points here, especially considering that there is seemingly no material difference between SuspensionList2021 and RevocationList2021 in the current version of this spec.

@msporny
Copy link
Member

msporny commented Aug 5, 2021

This is the direction I would hope to go - just allow a field like topic where the status topic can be whatever the list implementer wants (possibly with a registry of known values and their meanings).

Feels reasonable, especially since we don't have a test suite for interop yet... we'd want to get this locked in before one is created. I'm trying to think through how the change might blow up in our faces... I haven't had a chance to think deeply about that so would prefer some implementer feedback before we commit to the new design path.

The old design clearly specifies the type in both the VC that points to the status list, and the status list itself (so there can be no confusion on what the list is for). If we were to do this, there would be an extra type check required to make sure the topics line up... if we don't do that, there could be an attack where you swap a suspension list for a revocation list (maybe?!)... I don't know, but someone needs to think about the attacks around this deeply before we implement it. Has anyone thought through how one would attack a topic mismatch?

@sbutterfield
Copy link

sbutterfield commented Mar 8, 2022 •
edited
Loading

@msporny
Currently going through an implementation cycle of this myself, I have some thoughts:

A related question is whether the VC for the list have a type that MUST be "RevocationList2021" as stated, or would it also allow "SuspensionList2021" to align with the addition of allowing SuspensionList in the VC given to the holder?

I had planned on publishing separate Status List VCs, one for Suspension List, one for Revocation List, that's how I interpreted it anyway, and then each VC had a service reference back to its applicable Status List VC target resource. This way a VC could be revocable and/or suspendable in credential definition spec by the issuer.

especially considering that there is seemingly no material difference between SuspensionList2021 and RevocationList2021 in the current version of this spec.

I had looked at this a bit differently in implementation. Here were the rules intended for issuing parties:

  1. Suspended credentials can be un-suspended
  2. Revoked credentials can never be un-revoked... only re-issued

This ruleset implies the need for two separate bitstrings and two separate list types identifying those bitstrings, right?

if we don't do that, there could be an attack where you swap a suspension list for a revocation list (maybe?!)

If type is part of the digest for the Status List VC, then it should be impossible to override the verification of a Revocation List with a verification of the Suspension List, no?

@msporny
Copy link
Member

msporny commented Mar 8, 2022

If type is part of the digest for the Status List VC, then it should be impossible to override the verification of a Revocation List with a verification of the Suspension List, no?

Yes, exactly. +1 to everything you said above. There are at least two different types of status lists today (revocation and suspension, with dangerous ramifications wrt. mixing up one w/ the other).

We could further generalize this like we plan to do in the upcoming Data Integrity work (namely, by reusing something akin to the cryptosuite property):

https://w3c-ccg.github.io/data-integrity-spec/#example-a-dataintegritysignature-example-using-a-nist-ecdsa-2022-cryptosuite

So, another alternative might be:

  "credentialStatus": {
    "id": "https://dmv.example.gov/credentials/status/3#94567",
    "type": "StatusList",
    "statusType": "revocation-2021", <--- this would be a string, not a JSON-LD type
    "statusListIndex": "94567",
    "statusListCredential": "https://example.com/credentials/status/3"
  }

... and the list would look like this:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/vc-status-list-2021/v1"
  ],
  "id": "https://example.com/credentials/status/3",
  "type": ["VerifiableCredential", "StatusListCredential"],
  "issuer": "did:example:12345",
  "issued": "2021-04-05T14:27:40Z",
  "credentialSubject": {
    "id": "https://example.com/status/3#list",
    "type": "StatusList",
    "statusType": "revocation-2021", <--- this would be a string, not a JSON-LD type
    "encodedList": "H4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA"
  },
  "proof": { ... }
}

Food for thought...

@csuwildcat
Copy link

csuwildcat commented Mar 8, 2022 via email

@sbutterfield
Copy link

@msporny, +1 very much like the idea for a type to refer to a data integrity signature that itself is verifiable.

A challenge presented in our desired implementation:
-- credentialStatus: {} is currently specified as an object. How would we expect a verification agent to reconcile a credential that could be either revoked or suspended? Is there a semantic elsewhere in DID Core that allows for an array representation of status' on a VC?

@msporny
Copy link
Member

msporny commented Mar 9, 2022

How would we expect a verification agent to reconcile a credential that could be either revoked or suspended? Is there a semantic elsewhere in DID Core that allows for an array representation of status' on a VC?

Your answer is in the VC Data Model spec, namely, this line:

https://www.w3.org/TR/vc-data-model/#syntaxes -- "All other properties, if present, are represented as either a single value or an array of values."

So, the value associated with credentialStatus can be an array, and if you have a credential that could be either revoked or suspended, do this (eventually, per the suggestion above):

  "credentialStatus": [{
    "id": "https://dmv.example.gov/credentials/status/3#94567",
    "type": "StatusList",
    "statusType": "revocation-2021",
    "statusListIndex": "94567",
    "statusListCredential": "https://example.com/credentials/status/3"
  }, {
    "id": "https://dmv.example.gov/credentials/status/4#82930",
    "type": "StatusList",
    "statusType": "suspension-2021",
    "statusListIndex": "82930",
    "statusListCredential": "https://example.com/credentials/status/4"
  }]

It's going to end up being some variation of the example above once we get consensus on what the community wants to do here.

@sbutterfield
Copy link

@msporny Ha! Right there under "Syntactic Sugar"

This section describes some of these approaches, which will likely go unnoticed by most developers, but whose details will be of interest to implementers

😏
Thank you

@dlongley
Copy link
Contributor

I think we can simplify statusType values to: "statusType": "revoked", "statusType": "suspended" (and anything else we want). I don't think we need to use revocation-2021 values, etc. It also feels more natural given the binary state here, i.e., "revoked" is either set or not / true or false, as opposed to revocation-2021 is set or not / true or false.

The value space is just a string so we can always, if need be, get more complicated in the future, but let's start with simple values and chances are we won't need a more complicated future.

@msporny
Copy link
Member

msporny commented Mar 10, 2022 •
edited
Loading

@csuwildcat wrote:

our whole desire with Status List was to have a generic descriptor/model that featured the exact list-typing field you suggested

Yes, you did... right here: https://github.com/w3c-ccg/vc-status-list-2021/issues/2

I'd like to take this moment to admit that: "On this point, Dan Buchner was totally right, he is a true gentleman and a scholar, and we should've been listening to him all along." /cc @OR13 @kimdhamilton

You might also be happy that we're going to probably take the same approach w/ the Data Integrity cryptosuites: https://w3c-ccg.github.io/data-integrity-spec/#example-a-dataintegritysignature-example-using-a-nist-ecdsa-2022-cryptosuite

I'm not sure why that wasn't something folks were into previously

The thing that changed is that enough developers complained about having to create new JSON-LD Contexts for each cryptosuite, and the code churn that resulted in that, that we've tried to make things easier by eliminating that JSON-LD Context and code churn. If we do this right in the VC 2.0 work, you won't need a cryptosuite JSON-LD Context at all, it'll just be built into the base context for all VCs.

@msporny
Copy link
Member

msporny commented Mar 10, 2022

"statusType": "revoked", "statusType": "suspended"

I'm concerned that a developer might check that field, not read the spec (gasp), or try to understand how any of this works (double gasp), and presume the credential is revoked and/or suspended. :(

I'm also uncertain about removing a date stamp entirely from the status suite.

Food for thought.

@dlongley
Copy link
Contributor

@msporny,

I'm concerned that a developer might check that field, not read the spec (gasp), or try to understand how any of this works (double gasp), and presume the credential is revoked and/or suspended. :(

I think that will be quickly remedied by user complaints. Also, I expect that would be a "fail closed" type of scenario (some privilege not granted, etc.) and until it's remedied, no VC from any user (revoked/suspended or not) would work. So, I don't think it's that much of a concern.

I'm also uncertain about removing a date stamp entirely from the status suite.

The date stamping is useful for cryptographic suites because cryptography has a shelf life. Many of these "statuses" (at least "revoked" and "suspended" anyway) don't have a shelf-life in terms of their semantics. The "concept" of revocation doesn't expire, but non-quantum-safe cryptosuite XYZ 2021 is expected to.

It may still be useful to have a date on the spec itself (Status List 2021) -- because across all status types we're using a particular method to create some level of privacy protection. We may find this doesn't work as well in the future as it did in 2021 -- for some reason -- or that much more privacy preserving and still easily implementable methods are available in 2030.

@sbutterfield
Copy link

@dlongley, (forgive the uninformed inquiry) does json-ld provide no modality for something like a status or type to be situationally interpretable depending on the context in which it's used?

Seems to me, as an implementor anyways, that I'd want to allow a derived status type if required. revoked/suspended/inactive/unpaid/in-default/under-review are all contextually relevant types that a binary response can answer. Thus, as long as a spec provides a controlled algorithm for providing the binary response, and requires the document's generator to provide the context to the ecosystem interpreting it (often familiar with DSL of the type anyways), then couldn't that provide a better implementation pattern?

I'm admittedly still coming up to speed so forgive any sweeping assumptions.

@dlongley
Copy link
Contributor

dlongley commented Mar 10, 2022 •
edited
Loading

@sbutterfield,

@dlongley, (forgive the uninformed inquiry) does json-ld provide no modality for something like a status or type to be situationally interpretable depending on the context in which it's used?

Seems to me, as an implementor anyways, that I'd want to allow a derived status type if required. revoked/suspended/inactive/unpaid/in-default/under-review are all contextually relevant types that a binary response can answer. Thus, as long as a spec provides a controlled algorithm for providing the binary response, and requires the document's generator to provide the context to the ecosystem interpreting it (often familiar with DSL of the type anyways), then couldn't that provide a better implementation pattern?

So, with JSON-LD / RDF, you can make the semantics for a vocabulary term whatever you want in the text that defines it. What we're doing by using statusType and having it hold a string value is removing the requirement that authors must create new JSON-LD vocabularies and contexts and update implementations to install and use them whenever there is a need for a new type of status.

Instead, status types can be independently described in specs or along with the definitions provided for particular credential types and / or issuers. The verification software that needs to be able to report whether or not a particular status is set can then be separated from the business rules for evaluating what to do about a particular status in a given context -- which I think fits along with what you'd like to see here as well.

@sbutterfield
Copy link

@dlongley
Yep, I'm picking up what you're throwing down. There's a delicate balance there I didn't fully consider.

@msporny

I'm concerned that a developer might check that field, not read the spec (gasp), or try to understand how any of this works (double gasp), and presume the credential is revoked and/or suspended

I've seen some pretty bad design assumptions in my day (heck, I just made one) ... just my thoughts after reading both of your remarks:

  1. statusType should be harder to confuse in practice to a heedless dev
  2. statusType could be readable sans YYYY designation if its value is interpreted to be "for the purposes of" ... ie: instead of revoked as proposed or revocation-2021, use revocation. Instead of suspended use suspension, for example. Maybe instead of statusType it is statusPurpose or just purpose.
    I dunno 🤷🏻 , but I can see why this is such a hard thing to agree upon.

@msporny
Copy link
Member

msporny commented Mar 11, 2022 •
edited
Loading

2. statusType could be readable sans YYYY designation if its value is interpreted to be "for the purposes of" ... ie: instead of revoked as proposed or revocation-2021, use revocation. Instead of suspended use suspension, for example.

Yes, exactly this. @dlongley thoughts?

Maybe instead of statusType it is statusPurpose or just purpose.

Just "purpose" is a bit challenging because we try to use terms that are difficult to confuse outside of their used context. That is, the word purpose, used in other contexts, can mean different things. For example "proofPurpose", which is a real thing: https://w3c-ccg.github.io/security-vocab/#proofPurpose

We /could/ define one generic meaning for "purpose" that is used across all security contexts, but things have usually backfired when we've tried that in the past. That's not a hard and fast rule, though... we do have id and type and those are shared across ALL of JSON-LD to mean something very specific. We do also have challenge and domain... so, again, we've broken this general guidance before (in the early days... as in, nearly a decade or so ago).

At present, I think I'm leaning more towards statusSOMETHING... I find statusPurpose compelling, will need to think about it over the next week to see if any "shower/dishwashing thoughts" pop up.

I dunno 🤷🏻 , but I can see why this is such a hard thing to agree upon.

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. -- Leon Bambrick :P

@msporny
Copy link
Member

msporny commented Mar 11, 2022 •
edited
Loading

Alright, at this point, I think we're coming to consensus around these things:

  • The type field will include a year... StatusList2021.
  • We are adding a statusSOMETHING field; I'm leaning towards statusPurpose.
  • The statusSOMETHING field will contain a text string instead of a JSON-LD typed value.
  • We are removing the RevocationListX and SuspensionListX types.

This was referenced Mar 11, 2022
Closed
Merged
@msporny
Copy link
Member

msporny commented Mar 12, 2022

A PR has been raised to address this issue. @sbutterfield check out PR #24. All PRs in this repo (and most W3C repos) come w/ a "Preview" link in the initial PR comment. See this link for latest PR Preview: https://pr-preview.s3.amazonaws.com/w3c-ccg/vc-status-list-2021/pull/24.html

@dlongley
Copy link
Contributor

+1 to statusPurpose.

@Sakurann
Copy link
Contributor

PR merged. is this ready to be closed?

@msporny
Copy link
Member

msporny commented Jan 24, 2023

PR merged. is this ready to be closed?

The initial request asked to compare/contrast this spec against the Revocation List 2020 spec. Given that we plan to EOL Revocation List 2020 and that most implementers are moving to StatusList2021, I'm going to assert that we just not say anything about the old spec in the new spec, put a "this spec replaced by StatusList2021" on the old spec, and never talk about the old spec again. :)

The other part of the initial request was to add statusPurpose, which was done in PR #24.

I believe this addresses the initial request, so closing this issue. Re-open if you disagree, @swcurran.

@msporny msporny closed this as completed Jan 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@msporny @csuwildcat @dlongley @sbutterfield @swcurran @kezike @Sakurann