w3c-ccg / citizenship-vocab Goto Github PK

The spec includes "birthCountry" and then also includes phrases in the vocabulary definitions like "as specified by the country's official body".

I believe these are two different "countries".

Either the second use (in vocabulary) should change to "as specified by the issuer" or perhaps the credential should explicitly name the country and issuing authority (which may or may not be the birthCountry (and at least for US Permanent Resident Cards, the birth country will never be the issuing country).

Section 3.10 says:

Given that these digital credentials are understood to be a digital version of an underlying status, such as permanent residency, is there any value in keeping track of an issue date of that underlying status distinct from the issuance date of the actual credential?

This is not quite "resident since".

If we don't track the issue date of the underlying privilege, we may still need to track the authorization date for getting a digital credential. The issuance date is when the individual's identifier is bound to the credential digitally, presumably when just before they download it, which is not the same as when the issuing authority authorized a given person to retrieve the digital credential.

In short, there are three dates related to authorization and issuing:

1. issue date of the real-world credential, e.g., the issue date of the permanent resident card of which this is a digital version
2. authorization date for the beneficiary to be able to download the digital credential
3. issue date of the digital credential--when the digital credential is formally minted as a Verifiable Credential

Arguably, issue date 1 is tied to the physical credential and not relevant here. Alternatively, it may be that issue date 1 is the same as authorization date, if the digital credential is authorized when the real-world credential is issued.

Either way, we should figure out which of these is important to record. There is definitely a point in time before issuance where the credential is authorized. Since these two are distinct events, and the latter is dependent on the beneficiary, it seems they should both be captured.

This is such a standard feature of credentials like passports and driver's licenses, I would expect to see it here.

I pretty much never use http any more, but changing it to https WILL break signatures....

https://github.com/w3c-ccg/citizenship-vocab/blob/main/contexts/citizenship-v1.jsonld#L6

If there is a time to fix this, it's now, otherwise we will be telling users to review terms defined without ssl forever.

http://schema.org/Organization -> https://schema.org/Organization

schema.org automatically redirects, suggesting http should NOT be used.

Example 1 from the current draft when processing this with the JSON-LD playground appears to drop some of the terms in the expanded form namely all of those in the credential subject.

It looks like sometime over the past 24 hours the remote context that's identified by https://w3id.org/citizenship/v1 and redirects to https://digitalbazaar.github.io/citizenship-vocab/contexts/citizenship-v1.jsonld was broken.

Can we get the https://w3id.org/citizenship/v1 url to redirect to the context in this repo now?

is this something @iherman has to do or can chairs/editors do it?

pinging @msporny @peacekeeper @mavarley @dlongley @w3c-ccg/chairs for visibility

When will this move from the digital bazaar owned repo to the W3C CCG owned repo?

Not sure how to reflect this... but ideally we should emphasize how useful these are, and how great it is that we are reusing schema.org :)

JSON-LD https://digitalbazaar.github.io/citizenship-vocab/contexts/citizenship-v1.jsonld
HTML https://digitalbazaar.github.io/citizenship-vocab/