Common JSON-LD schema

[pramodkvarma]

@dileepbapat can you please let me know where are the JSON-LD schema definition for common elements? I see a set of JSONs in common folder but not schemas. Now that we have multiple credential specs here, it is critical that all specs including common elements are harmonized and made available as JSON-LD schemas. Can you comment please? @kochhar FYI as well.

[dileepbapat]

These files are in json schema format, since json schema allows defining constraints, type and structure we are using these as source of truth for schema. I will add equivalent jsonld schemas in respective folders.

[pramodkvarma]

Thank you!

@kochhar please provide inputs and do PRs as necessary to co-create this with @dileepbapat

[dileepbapat]

writing a quick transformer to generate context files based on json schema, will add it soon

[dileepbapat]

Added transpiler and generated content https://github.com/sunbird-specs/vc-specs/tree/acb94c016f079db202e5b5c48fa6f4d32b133776

[pramodkvarma]

Thanks @dileepbapat for getting the JSON-LD schemas in.

@kochhar can you please check out, comment, and align Proof of Work schema to these? Thanks.

@kamyachandra just FYI in case you missed this thread.

[kochhar]

@dileepbapat I was looking at the generated JSON-LD and trying to align with the VC data-model published here:
https://www.w3.org/TR/vc-data-model/#types

Couple of questions:

1. Which of the VC data model types does CredentialBase align with?
2. Is the Subject intended to augment the credentialSubject type from the VC data-model?
3. The VC spec requires the @id identifiers to be in URN form. For credentailSubjects what URN scheme is intended to be used?
4. What are the thoughts around the privacy implications of mandatory embedding of contact details into the credential?

[pramodkvarma]

Couple quick comments.

For 3, can we use the did URI structure (like did:in.aadhaar:123456789012 etc). Or am I understanding incorrectly?

For 4, we shouldn't be mandating such details like phone, email, address, etc and simply provide capability in schema to optionally capture it. Implementing agencies can align with country specific laws and practices to make judgement about these.

We could also allow either whole VC or parr of it being encrypted (say, using a user specified passphrase). So from schema perspective, we should allow capability to indicate that the value of an element is encrypted along with encryption scheme reference.

[dileepbapat]

1. CredentialBase is extension on VerifiableCredential, some of the fields like issuedOn and signedOn etc are inspired by other digital signature data models (referred eu and us-cert public documents). If you are talking about issuer being redefined, I will exclude in the generation code.

"type": ["VerifiableCredential", "CredentialBase", "ProofOfSkill"]

2. Yes, based on domain we can define common subject / person identifiers and reused in actual VCs
3. Preferable to be did format
4. As Pramod mentioned these are optional attributes if exists it can be attributed with specific semantic meaning by jsonld node and type mapping. Again, this is just draft open for modification!

[kochhar]

Thanks @dileepbapat @pramodkvarma, these are really helpful notes to get me going. I think I can incorporate the base schemas from here.

Re: did identifiers

1. this is great -- we can use as is.
2. For DIDs, should we publish a list of did method names (in.aadhaar, in.pan, in.voter-id, in..driving-license? Perhaps this should be published outside the individual specs in a user/implementer manual.
   1. Also wondering if the did method name should include a reference to issuer namespace? (i.e. in.gov.uidai.aadhaar, in.gov.itd.pan, in.gov.eci.voter-id., in.ka.gov.driving-license)
   2. For prior art in this area, you could refer to the New Zealand govt URN namespace NZL.

A couple of notes on synonymous properties available from VC and other vocabs:

1. credentialId should likely by a synonym for @id since the latter is a required part of the credential
2. [issuanceDate](https://www.w3.org/TR/vc-data-model/#issuance-date) seems a good fit for issuedOn
3. validFrom and validUntil are included in the base context for VC
4. schema.org provides birthDate and gender which could be used
5. foaf provides phone which uses "tel: / " URI scheme to represent phone numbers

If the intents of the fields in the common schemas are aligned with these, I can include edits in my next PR to mark these as synonyms. We may be able to simplify by defining a couple of standalone properties in-place of the CertificateBase and IdentityDetail types.

Let me know your thoughts. Will share an updated PR shortly.

[pramodkvarma]

Yes, we should create standard formats for known Indian DIDs.

Yes, I prefer full namespace, but for DL etc, difficult to qualify with state ID etc. So may be easier to simply use in.<id> for all core IDs given within India these are well understood. But we can allow fully qualified namespace when it is necessary.

When it comes to phone/email etc simply use available ones like tel: or email: etc.

[dileepbapat]

1. Limitation with id is it has format constraints, might not be applicable in all contexts. credentialId can be domain specific identifier if it chooses to be non-IRI, its ok
2. issuanceDate as per definition date when cred becomes valid, for existing ids issuedOn can be actual issuance of ID / credential (may be non-digital). There is also signingDate. also issuanceDate can be in future.
3. Yes (same as issuer, will check for conflict and remove)
4. Yes type map is not updated for all properties, need to map many in https://github.com/sunbird-specs/vc-specs/blob/main/type_map.yaml. However we connot use schema.org/Address, might need to remap certain fields to support local address properly.
5. Yes, contact can be collection of URIs. however since mobile / sms used for OTP purpose we might need to tread few contact channels as mandatory based on the usecase.

[kochhar]

2. issuanceDate can be date in the past/future -- from a validation PoV the specific use-case can choose whether such dates are acceptable.
   a. Per VC specs, issuanceDate is being deprecated in favour of issued and validFrom properties -- hence suggest that not to create synonymous properties and utilise the combination of issued, signedDate, validFrom and validUntil to cover the needs.
   b. Also suggest a standard naming scheme for such properties, renaming signedDate either to signed or signedOn
3. Yes, will use Sunbird VC address, it's a better fit
4. Credentials can be long-lived and are immutable -- contact information may evolve. Credential should reference the identity and contact details may be attached to the identity for verification (eg: Aadhaar OTP)