- From: Ashley Harwood <ashley.harwood@gosource.com.au>
- Date: Tue, 14 Nov 2023 18:13:03 +1100
- To: "Charles E. Lehner" <cel@celehner.com>
- Cc: public-credentials@w3.org
- Message-ID: <CAMJ6LWGykwRvnDsBk4E0=-XvKFnGKSPv+AqMHpv5uLsPCFHbtQ@mail.gmail.com>
Hi Charles,
Again, I appreciate the response.
VerifiableCredential and credentialSubject are protected by the base
> context (VCDM v1-v2).
>
Yes, that is why I was seeking clarification.
Employee could be defined in the top-level context.
>
I believe this causes the same issue I'm seeking a resolution to, but at a
deeper level, EmployeeCredential > Employee that is.
A new top-level property could be used.
While technically possible, we would prefer to stick with the
credentialSubject property.
This definition of "name" aligns with the next version of the data model
> which defines it now for the credential and issuer.
>
I wasn't aware of this, and it's helpful information. However, the property
name I selected for the example is just that – an example. Therefore, we
will still face the same issue.
Many Thanks,
Ashley
On Tue, 14 Nov 2023 at 15:21, Charles E. Lehner <cel@celehner.com> wrote:
> Employee could be defined in the top-level context. e.g.:
> {
> "@context": [
> "https://www.w3.org/2018/credentials/v1",
> {
> "@protected": true,
> "EmployeeCredential": "https://example.com#EmployeeCredential",
> "Employee": {
> "@id": "https://example.com#Employee",
> "@context": {
> "@protected": true,
> "name": "https://schema.org/name"
> }
> }
> }
> ],
> "type": [
> "VerifiableCredential",
> "EmployeeCredential"
> ],
> "credentialSubject": {
> "type": "Employee",
> "id": "did:example:foo",
> "name": "Foo Foo"
> },
> ...
> }
>
> VerifiableCredential and credentialSubject are protected by the base
> context (VCDM v1-v2) so cannot be redefined to make scoped definitions. If
> the nested scoping is needed, a new top-level property could be used, but
> "credentialSubject" is still required; this might be considered
> non-idiomatic:
> {
> "@context": [
> "https://www.w3.org/2018/credentials/v1",
> {
> "@protected": true,
> "cred": "https://www.w3.org/2018/credentials#",
> "EmployeeCredential": {
> "@id": "https://example.com#EmployeeCredential",
> "@context": {
> "@protected": true,
> "employeeCredentialSubject": {
> "@id": "cred:credentialSubject",
> "@type": "@id",
> "@context": {
> "@protected": true,
> "Employee": {
> "@id": "https://example.com#Employee",
> "@context": {
> "name": "https://schema.org/name"
> }
> }
> }
> }
> }
> }
> }
> ],
> "type": [
> "VerifiableCredential",
> "EmployeeCredential"
> ],
> "credentialSubject": {
> "id": "did:example:foo"
> },
> "employeeCredentialSubject": {
> "id": "did:example:foo",
> "type": "Employee",
> "name": "Foo Foo"
> },
> ...
> }
>
> This definition of "name" aligns with the next version of the data model
> which defines it now for the credential and issuer:
> https://www.w3.org/ns/credentials/v2
> https://www.w3.org/TR/vc-data-model-2.0/#names-and-descriptions
>
> https://www.w3.org/TR/2023/WD-vc-data-model-2.0-20231104/#issue-container-generatedID-51
> (some schema.org terms considered stable by VCWG)
> --
>
> On Tue, 14 Nov 2023 09:11:25 +1100
> Ashley Harwood <ashley.harwood@gosource.com.au> wrote:
>
> > Hi Charles,
> >
> > Thank you for your response. If I have interpreted your response
> > correctly, the "credentialSubject" would have the type of "Employee"
> > like so:
> >
> > {
> > "VerifiableCredential": {
> > "@id":
> > "https://www.w3.org/2018/credentials#VerifiableCredential",
> > "@context": { "credentialSubject": {
> > "@id": "cred:credentialSubject",
> > "@type": "https://example.com#Employee"
> > }
> > //...
> > }
> > //...
> > }
> > }
> >
> > Do I have this right?
> >
> > Many Thanks,
> > Ashley
> >
> >
> > On Mon, 13 Nov 2023 at 15:58, Charles E. Lehner <cel@celehner.com>
> > wrote:
> >
> > > Hi Ashley,
> > >
> > > I think the type "Employee" should be of the credential subject.
> > > Then your scoped context definition for the "name" property should
> > > work. The credential could have a different 2nd type, e.g.
> > > "EmployeeCredential".
> > >
> > > Regards,
> > > Charles
> > >
> > > On Mon, 13 Nov 2023 11:24:48 +1100
> > > Ashley Harwood <ashley.harwood@gosource.com.au> wrote:
> > >
> > > > Hello everyone,
> > > >
> > > > I'm seeking advice on the proper way to specify a type for the
> > > > subject in a verifiable credential with the use of context.
> > > >
> > > > My understanding was that typing a Verifiable Credential as
> > > > follows:
> > > >
> > > > "type": [
> > > > "VerifiableCredential",
> > > > "Employee"
> > > > ]
> > > >
> > > > and then defining a context like this:
> > > >
> > > > {
> > > > "@context": {
> > > > "@version": 1.1,
> > > > "@protected": true,
> > > > "Employee": {
> > > > "@id": "https://example.com#Employee",
> > > > "@context": {
> > > > "name": "xsd:string"
> > > > }
> > > > }
> > > > }
> > > > }
> > > >
> > > > followed by constructing the credential in this manner:
> > > >
> > > > {
> > > > "type": [
> > > > "VerifiableCredential",
> > > > "Employee"
> > > > ],
> > > > "@context": [
> > > > "https://www.w3.org/2018/credentials/v1",
> > > > "https://example.com/employee.jsonld"
> > > > ],
> > > > "credentialSubject": {
> > > > "id": "{{EMPLOYEE_DID_WEB}}",
> > > > "name": "Ashley"
> > > > }
> > > > //...
> > > > }
> > > >
> > > > would establish the necessary context for the credential subject.
> > > > However, I encounter errors indicating that the "name" is not
> > > > defined in the context.
> > > >
> > > > I know that using:
> > > >
> > > > "@vocab": "https://www.w3.org/ns/credentials/issuer-dependent#"
> > > >
> > > > acts as a universal solution for undefined terms, yet it
> > > > compromises validation during credential creation.
> > > >
> > > > I'm also aware that defining terms "inline" like this:
> > > >
> > > > {
> > > > "@context": [
> > > > {
> > > > "@version": 1.1
> > > > },
> > > > "https://www.w3.org/ns/odrl.jsonld",
> > > > {
> > > > "name": "xsd:string"
> > > > }
> > > > ]
> > > > }
> > > >
> > > > works but appears to go against the grain of JSON-LD's intent and
> > > > disrupts the link between the credentialSubject and 'Employee'
> > > > definition.
> > > >
> > > > Am I overlooking an aspect of this process?
> > > >
> > > > Many Thanks,
> > > > Ashley
> > > >
> > >
> > >
> >
>
--
---
The content of this email and attachments are considered
confidential. If you are not the intended recipient, please delete the
email and any copies, and notify the sender immediately. The information
in this email must only be used, reproduced, copied, or disclosed for the
purposes for which it was supplied.
Received on Tuesday, 14 November 2023 07:13:21 UTC