- From: Andy Miller <theafmiller@gmail.com>
- Date: Tue, 14 Nov 2023 17:23:05 +0900
- To: Ashley Harwood <ashley.harwood@gosource.com.au>
- Cc: "Charles E. Lehner" <cel@celehner.com>, public-credentials@w3.org
- Message-ID: <CACd75VUC2NmUVYs6u4SsGq_EwJr2FfKomLvgzi5zPD6e3hqB0Q@mail.gmail.com>
Hello Ashley,
1EdTech's Open Badges Specification 3.0
<https://www.imsglobal.org/spec/ob/v3p0/> defines a number of types, each
with specific properties such as "OpenBadgesCredential" (and it's synonym
"AchievementCredential") and "AchievementSubject". A basic Open Badges VC
looks like this:
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json"
],
"id": "http://example.com/credentials/3527",
"type": ["VerifiableCredential", "OpenBadgeCredential"],
"issuer": {
"id": "https://example.com/issuers/876543",
"type": "Profile",
"name": "Example Corp"
},
"issuanceDate": "2010-01-01T00:00:00Z",
"name": "Teamwork Badge",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": "AchievementSubject",
"achievement": {
"id": "https://example.com/achievements/21st-century-skills/teamwork",
"type": "Achievement",
"criteria": {
"narrative": "Team members are nominated for this badge by their peers
and recognized upon review by Example Corp management."
},
"description": "This badge recognizes the development of the capacity to
collaborate within a group environment.",
"name": "Teamwork"
}
}
}
The OB types are defined in "
https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json". The "@type" of
the credential is ["VerifiableCredential", "OpenBadgeCredential"]. And the
"@type" of the credential subject is "AchievementSubject".
You could use a similar approach with your credential.
Andy
On Tue, Nov 14, 2023 at 4:15 PM Ashley Harwood <
ashley.harwood@gosource.com.au> wrote:
> 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 08:24:22 UTC