Authoritative document issuers

[davux]

Introduction

It's sometimes useful to describe the fact that a person or an organization has some authority as an issuer for specific kinds of documents. Or course, "authority" is to be understood in general terms of other people's trust, not necessarily in legal or institutional terms. (Recognition of institutions is just one particular trust policy.)

For instance:

• University X is described as a trusted authority for issuing doctor diplomas.
• John Doe is described by his friends as a good authority for claiming that someone knowsAbout art.
• Tech Organization X is seen by some as an authority for issuing Cloud certifications.
• Country/State X is seen by some other countries/states as an authority for delivering valid driving licenses.

Proposed approach

I'd like to propose something like:

• A new IssuerScope class, describing the scope of authority of an entity.
  • That class has a main attribute called issuerFor (or similar, like issuesAbout, authoritativeFor...), of type Thing (be it some CreativeWork, a schema attribute, or even a descriptive text).
  • More attributes can appear to further define a scope, such as a delegation depth (see below).
• Extending Person and Organization with a new hasIssuingAuthority attribute (or similar name) of type IssuerScope.

Examples

Example 1a. To express an entity's authority to make an affirmation about someone's birth date.

"hasIssuingAuthority": {
    "@type": "IssuerScope",
    "issuerFor": {
      "@id": "http://schema.org/birthDate",
      "@type": "Property"
  }
}

Example 1b. Same thing, shorter (without @type and taking into account @context).

"hasIssuingAuthority": {
  "issuerFor": "birthDate"
}

Example 2. To express an entity's authority to issue a specific type of VerifiableCredential, namely a UniversityDegreeCredential.

"hasIssuingAuthority": {
  "issuerFor": {
    "@id": "https://www.w3.org/2018/credentials/examples/v1/UniversityDegreeCredential",
    "@type": "Class" // or should it be "https://www.w3.org/2018/credentials/v1/VerifiableCredential"?
  }
}

Example 3. To express an entity's authority to claim that someone knows about art. I'm not sure how to restrict acceptable values (or whether we want to).

"hasIssuingAuthority": {
  "issuerFor": {
    "@id": "knowsAbout",
    "@type": "Property",
    acceptableValue: ["Art"] // Not sure how to express this
}

Example 4. To express an entity's authority to issue Microsoft Azure certifications.

"hasIssuingAuthority": {
  "issuerFor": "Azure Architect Level 4 Certification" // Text
}

Example 5. To express that an entity is able to issue invoices.

"hasIssuingAuthority": {
  "issuerFor": {
    "@id": "http://schema.org/Invoice",
    "@type": "Class"
  }
}

Delegation

On top of that (and optionally), it should be possible to express delegation of such authority. I'm thinking of a delegationDepth attribute in the IssuerScope class, representing a number of hops (defaulting to 0, meaning no delegation).

Anyone inheriting a capability by delegation can claim the same IssuerScope about another entity, but with a delegationDepth that is strictly lower than their own.

Example 6. To express an entity's authority to either directly issue Azure Certifications or name authorities to do so (i.e. 1 hop).

"hasIssuingAuthority": {
  "@type": "IssuerScope",
  "issuerFor": "Azure Architect Level 4 Certification"
  "delegationDepth": 1
}

Possible uses

One example of useful applications of such a schema, including the delegation part, is in a Verifiable Credential, as it enables the description of chains of trust – similar to X.509's CA chains but with richer semantics. We're trying it out in the KayTrust project as described in this WIP document along with a proof-of-concept VC implementation, but we don't want to go too far without involving the schemaorg community on the schema level first (regardless from whether it's applied on VCs or anywhere else).

What do you think?

[RichardWallis]

Need to think about it more before generally commenting.

However, the delegation part of the proposal seems to raise more questions than the information provided.

delegationDepth immediately raises the question of whom is the delegation from and what is their authority?

Wouldn't a property authorityDelegatedFrom with a range of Person or Organization be more informative and useful?

[davux]

However, the delegation part of the proposal seems to raise more questions than the information provided.

delegationDepth immediately raises the question of whom is the delegation from and what is their authority?

Do you mean the authority of claiming that there's a certain delegation level? The whole scope comes from the same entity, i.e. it's the same source that says Org X is an issuer for Azure certifications and that they can delegate it down to a certain level.

It's a way for Org X to use the capability they already have. It can be read like this (in comments):

// Some context (API response, microformat, Verifiable Credential...)
{
  // about, say, an Organization
  "hasIssuingAuthority": {
    "@type": "IssuerScope",
    "issuerFor": "Azure Architect Level 4 Certification", // The context claims this Person|Org can issue Azure Certifications. (We're not saying how.)
    "delegationDepth": 1 // Instead of issuing Azure Certifications directly, they can delegate that authority (minus 1 depth level) to another entity. (We're not saying how either.)
  }
}

I hope that's clearer.

Wouldn't a property authorityDelegatedFrom with a range of Person or Organization be more informative and useful?

I like it. It's a different strategy than delegationDepth and I think there are valid contexts for either. It's definitely a good way to trace the path back, so I think it would be nice as an additional property of IssuerScope.

[RichardWallis]

Clearer now.

Is the depth value important? To me, having delegationAbility or delegationCapability True/False would provide the indication you describe.

[WeaverStever]

Can this fold into expanding https://schema.org/identifier? Related discussion? #2778

[davux]

@RichardWallis, sure it looks sufficient. However, what would the delegatee's own delegationCapability look like? That's why I'm suggesting we use a number of hops.

[davux]

@WeaverStever, I'm not sure... What would be the identifier?

[WeaverStever]

@davux

Doesn't the issuing authority almost always provide some sort of Identifier? One for the certificate itself and a serialized certificate to the individual holding it? For instance, ASAE is some level of Azure certification.

If you look at https://schema.org/identifier there are some well known identifying authorities as canned sub-properties, so the issuing authority is presumed. Others are ad-hoc as in this example.

 "identifier": {
 "@type": "PropertyValue",
   "propertyID": "ASAE",
   "value":  "889647468",
   "url": "https://example.com/somePDFfile.pdf",
   "description": "I passed my tests on spring break 2019"
   }

At present, Identifier only has three properties, PropertyValue, Text, URL.

Within https://schema.org/PropertyValue, we seem to be missing items like issuing authority.

Additionally, from the example above, if we provide a url in PropertyValue, my assumption would be that is is some form of proof of good-standing. PropertyValue is missing items like beginDate, endDate, issuingAuthority, etc.

[davux]

@WeaverStever, this proposal is only about describing someone (Person or Organization) as authoritative for issuing a given type of certification. It doesn't say anything about the data model of what's being issued. I hope that's clearer!

[WeaverStever]

@davux

@WeaverStever, this proposal is only about describing someone (Person or Organization) as authoritative for issuing a given type of certification. It doesn't say anything about the data model of what's being issued. I hope that's clearer!

Yes, I see that, but I also see that it seemingly fits into the Identifier property that needs improvement - extending. When I look at the https://schema.org/PropertyValue under the context of Identifier, it appears to be about standards and measurements.

The same properties you are suggesting would also be useful to the person who earns the certification, as well as the issuing authority.

Example:
For Instance, the ISNI, is ISO certified, so in this case ISNI is International Standard Name Identifier, there is an issuing authority and a parent standards agency, so to disambiguate from other uses for ISNI, more properties could be useful.

A quick google search shows that the International Congress of Neuroimmunology Invitational also uses the ISNI acronym.

[github-actions]

This issue is being tagged as Stale due to inactivity.