Repository navigation
Update credentialStatus checks. - #170
Conversation
- Make "id" optional. - If "id" present, check it's a URL. - Add tests.
| .contain('"credentialStatus.id" must be a URI'); | ||
| }); | ||
|
|
||
| it('should accept "credentialStatus" with no "id"', () => { |
There was a problem hiding this comment.
is this 1.0 or 2.0? in 2.0 I'm showing: https://w3c.github.io/vc-data-model/#status
credentialStatus
If present, the value of the credentialStatus property MUST include the following:
id property, which MUST be a URL which MAY be dereferenced.
type property, which expresses the credential status type.
so it should not accept a credentialStatus with no id. @davidlehn
There was a problem hiding this comment.
also checked and in 1.1 credentialStatus.id must be a url and present:
https://www.w3.org/TR/vc-data-model/#status
credentialStatus
If present, the value of the credentialStatus property MUST include the following:
id property, which MUST be a URI.
type property, which expresses the credential status type (also referred to as the credential status method). It is expected that the value will provide enough information to determine the current status of the credential and that machine readable information needs to be retrievable from the URI. For example, the object could contain a link to an external document noting whether or not the credential is suspended or revoked.
There was a problem hiding this comment.
to summarize: in vc 2.0 credential status id is becoming optional because specs that define credential status(es) don't necessarily want to make information like id available. So in the higher level spec (VC 2.0) id will become optional and then depending on the credential status spec id will be required or not.
|
@dlongley @davidlehn just to make sure we want credentialStatus id to be optional in 1.0, 1.1, and 2.0? I know we want it optional in 2.0, but just making sure. |
|
There is a status type spec that says it's optional, 1.0 and 1.1 say id MUST be included, and 2.0 is making id optional. This seems like an oversight in 1.x specs more than something that should be enforced. I'm not sure what to say for testing in this situation. Perhaps ideally it would be tested as optional, and errata would be written for 1.0 and 1.1 to clarify the issue for implementations. That takes a bit of work though. In any case, leave some comments near the tests so people understand the issue. |
so the question is, as the vc 2.0 branch still supports VC 1.0 issuance/verification etc, is should we check the context of the VC and then have an optional check if 2.0 and a required check if 1.0 for |
|
This library should not require |
|
PR merged @BigBlueHat be advised this PR has received new functionality: #168 |
This matches 1.x spec, and is currently an open issue in 2.0 work.