Revocable indicator

[nissimsan]

Parameter to indicate credential revocability.

[msporny]

Why not just a true/false value here?

[msporny]

How is this intended to work with credentialStatus -- doesn't that indicate whether or not the VC is revocable? For example: https://github.com/w3c-ccg/vc-http-api/pull/211/files#L53 ... I think we already have this feature:

 "credentialStatus": { "type": "RevocationList2020Status" }

^^^ that indicates that the VC is revocable.

[OR13]

right now, you are required to submit a credential with a member of the following form:

    "credentialStatus": {
      "id": "https://issuer.oidp.uscis.gov/credentials/status/3#94567",
      "type": "RevocationList2020Status",
      "revocationListIndex": "0",
      "revocationListCredential": "https://w3c-ccg.github.io/vc-http-api/fixtures/revocationList.json"
    },

perhaps it would be better to define this shape, and note that when it is present the credential MUST have an id.

Using the API today, you can issue revocable credentials, you just need to know how to hand crafter perfect JSON-LD to do it...

[OR13]

I guess the question this raises, is... is the issuer really doing issuance, if they are not checking that the credentialStatus is wellformed? why are folks accepting / issuing vc's with credentialStatus that point to a CCG github repo?

I would expect an issuer to maintain their own list, or at the very least validate this entry from a schema perspective.

[OR13]

Prefer to see the data shape of a "revocable vc" defined in json schema and referenced, we don't appear too have consensus on how to "issue a revocable VC", but its possible to document how its done today as a first step... and to be clear, the only way to do this today, is to hand craft the VC payload and call the issue API.

[msporny]

This is related to #204 -- at the very least, we need to determine how the client tells the issuer that they 1) manage the revocation list, or 2) use an external revocation list.

[msporny]

Now that history has been filtered on main, this PR doesn't line up and shouldn't be merged as is. Do you want to raise a new PR, or rework this one, @nissimsan?

[OR13]

I agree, suggest reimplementing.

[nissimsan]

Hi guys - thanks!

I'll close this in any case to avoid github gymnastics.

I don't see much support for a less-techie-user-friendly approach which shields users from the intricacies of credentialStatus. It makes sense for the vc-http-api not to go into such default-behavior use case. So not planning on reopening the ticket. (Please let me know if I misinterpret your dialogue).

[OR13]

@nissimsan my suggested changes was to define credentialStatus correctly here:

https://github.com/w3c-ccg/vc-http-api/blob/main/components/Credential.yml

as an optional field.

[nissimsan]

@OR13, the credentialStatus field is already defined on IssueCredentialsOptions (not Credentials, as you suggest):
https://github.com/w3c-ccg/vc-http-api/blob/main/components/IssueCredentialOptions.yml#L38

I'm slightly hesitant - an "optional" field does seem to fit okay on the "options" object (passed right along the Credentials object at issuance). So, just confirming: is moving the field indeed what you had in mind?

[OR13]

@nissimsan yes, I thought it would be best to focus on keeping the types as close to their output format as possible.

I suppose this could be improved by describing how revocable credentials are issued with these APIs directly, including how the options is used to mutate the request body before signing... generally mutating request bodies should be minimized.