Verification Service Profile updates

Per our 2023-02-07 meeting: The current implementation of Verification Service Profile presents undue difficulties in data maintenance workflows when new Credentials are published. This is because the VSP hangs directly off of the Organization, and references applicable Credentials, which means that when a new Credential is published (or the service no longer applies to a given Credential), the VSP must also be updated, and the Organization republished. This is technically feasible, but more difficult than it needs to be. It also makes looking up which credentials have which verification services more roundabout than it needs to be.

There are two proposals to solve this problem, generally favoring the first:

Decouple Organizations and VSPs by making VSPs top-level objects (ie giving them CTIDs) and add a property (TBD) to the various Credential classes that enables each Credential to reference its applicable VSP.
- Pro: This would negate the need to update the VSP and the Organization data when a new Credential is published
- Con: It is unclear how to interpret the data when the VSP references some list of Credentials, but that list of Credentials may or may not mirror that listing (ie if the VSP and Credentials are not kept in sync, the connections will not exactly mirror each other).
- Con: This would require a number of system/infrastructure updates to facilitate this change
Remove the VSP from the picture as a requirement and enable Credentials to reference a Claim Type directly
- Pro: This greatly simplifies the data model and publishing/consuming of the data
- Con: Without a VSP (which would be optional), there would be no way to document the details of the service itself, as all that could be said is "this credential is verified with this type of claim"
- Con: It is unclear how to interpret the data when the VSP references some list of Credentials, but that list of Credentials may or may not mirror that listing (ie if the VSP and Credentials are not kept in sync, the connections will not exactly mirror each other).
- Con: If we changed our mind and decided to implement option 1 later, there would be a lot of messy/redundant data where Credentials reference both a VSP and a claim type

Per our 2-28-2023 meeting:

Modify the definition for claimType:VerifiedClaim:
- From: Verifiable representation of the credential holder's credential.
- To: Verifiable representation of the credential holder's achievement.
Add CTID to Verification Service Profile
Create ceterms:usesVerificationService property
- Label: Uses Verification Service
- Definition: Reference to a service that is used to verify this Credential.

Also, explore how to reference a standalone badge from a standalone credential in a way that signifies that the badge represents the credential, for cases where simply having a badge claim through a verification service is not sufficient.

Per our 3-7-2023 meeting:

Proposal: Make Verification Service Profile a top-level object with a CTID: Add:

Subject: ceterms:ctid Predicate: schema:domainIncludes Object: ceterms:VerificationServiceProfile

Update the definition for claimType:VerifiedClaim to be broader: Remove:

Subject: claimType:VerifiedClaim Predicate: skos:definition Object: Verifiable representation of the credential holder's credential.

Add:

Subject: claimType:VerifiedClaim Predicate: skos:definition Object: Verifiable representation of the credential holder's achievement.

Create ceterms:usesVerificationService property:

URI: ceterms:usesVerificationService Label: Uses Verification Service Definition: Reference to a service that is used to verify this Credential. Domain: ceterms:Credential (and subclasses) Range: ceterms:VerificationServiceProfile

@siuc-nate (minor stuff first) am I right in thinking that in the diagram above, the link between Verification Service Profile and claimType:BadgeClaim should be ceterms:verifiedClaimType not claimType as shown?

Also, on what you were discussing at the end of our call on 2023-03-21, both the Badge and the Certification will have the property usesVerificationService and I think using it on either makes sense; however, it is more important that it is shown on the Certification data in the registry because it is inherent to [Open]Badges that they contain references to how they can be verified, no need for anyone to look up info on how to verify them.

Which raises the final question: does the specific use case we have use OpenBadges (or similar) as the verifiable representation? --It's Nate Otto so I'm guessing yes, and I think that is what Deb was saying yesterday.

Do we need a definition for hasVerifiableRepresentation in the proposal?

If we do, tweaking what is in the diagram, I would say

URI: ceterms:hasVerifiableRepresentation Label: Has Verifiable Representation Definition: Reference to an inherently verifiable representation of the achievement. Comment: An inherently verifiable representation is one that contains details of how to verify it, for example an OpenBadge or W3C Verifiable Credential. Domain: ceterms:Credential (and subclasses) Range: rdfs:Resource? or ceterms:Credential (and subclasses)

Otherwise, if we don't need this, bottom line is that I am happy with the changes as outlined

am I right in thinking that in the diagram above, the link between Verification Service Profile and claimType:BadgeClaim should be ceterms:verifiedClaimType not claimType as shown?

Yes - good catch.

We should probably tackle the proposal in my previous post first, as I think we're all in agreement that that part of it is needed. The verifiable representation stuff isn't as settled yet, and could perhaps be a second issue after the agreed upon stuff from this one is added to the schema (we are running out of time to do so this month)

I think people are in a rush to implement.

@jeannekitchens : Is what is in the proposal above enough for that or do we need to include hasVerifiableRepresentation?

URI: ceterms:hasVerifiableRepresentation Label: Has Verifiable Representation Definition: Reference to an inherently verifiable credential that would be issued as a representation of this achievement. Comment: An inherently verifiable representation is one that contains details of how to verify it within the issued credential, for example an OpenBadge or W3C Verifiable Credential. UsageNote: To verify an individual's achievement, use the instance of the inherently verifiable credential issued to that individual. Domain: ceterms:Credential (and subclasses) Range: rdfs:Resource

Combined Proposal March 28, 2023:

Proposal: Make Verification Service Profile a top-level object with a CTID: Add:

Subject: ceterms:ctid Predicate: schema:domainIncludes Object: ceterms:VerificationServiceProfile

Update the definition for claimType:VerifiedClaim to be broader: Remove:

Subject: claimType:VerifiedClaim Predicate: skos:definition Object: Verifiable representation of the credential holder's credential.

Add:

Subject: claimType:VerifiedClaim Predicate: skos:definition Object: Verifiable representation of the credential holder's achievement.

Create ceterms:usesVerificationService property:

URI: ceterms:usesVerificationService Label: Uses Verification Service Definition: Reference to a service that is used to verify this Credential. Domain: ceterms:Credential (and subclasses) Range: ceterms:VerificationServiceProfile

URI: ceterms:hasVerifiableRepresentation Label: Has Verifiable Representation Definition: Reference to an inherently verifiable credential that would be issued as a representation of this achievement. Comment: An inherently verifiable representation is one that contains details of how to verify it within the issued credential, for example an OpenBadge or W3C Verifiable Credential. UsageNote: To verify an individual's achievement, use the instance of the inherently verifiable credential issued to that individual. Domain: ceterms:Credential (and subclasses) Range: rdfs:Resource

Regarding examples: I am opposed to adding the ceterms:hasVerifiableRepresentation property for all the reasons I've gone into at length, so I am not the correct person to try to justify it with an example. But, as a starting point:

What actual, tangible value is added by the third object in the list of objects in the JSON-LD below?
Does that value outweigh the overhead incurred by requiring publishers to publish, maintain, update, etc., two credentials, two CTIDs, for every credential they have instead of just one?
Does that value outweigh the overhead incurred by people searching the registry or the Finder, who will now see a bunch of (to them) duplicate credentials, and not know which one to download/click on?
Which one's CTID is the canonical CTID for the credential?
Which CTID would you use for links from other places (e.g. wallets), and why?
Which one's Finder page would you link to from those same other places, and why?
Won't publishers complain about us doubling their workload (they've complained about far less in the past)?
Shouldn't the Badge reference the Certification, rather than the other way around? Someone consuming the badge will not know what it is a badge for, whereas someone consuming the Certificate shouldn't need the Badge at that point.

I think our original mistake was constructing ceterms:Badge and its subclasses as standalone credentials, rather than representations/proxies. I could perhaps see the justification then, semantically - though the practical problems above (including the CTID, given the way our systems work) would still be true.

{
    "@id": "res:vsp",
    "@type": "ceterms:VerificationServiceProfile",
    "ceterms:ctid": "abcdef",
    "ceterms:name": { "en": "Badge Verification for CompTIA" },
    "ceterms:subjectWebpage": "https://...",
    "ceterms:verificationService": "https://...",
    "ceterms:verificationDirectory": "https://...",
    "ceterms:offeredBy": [
        "res:ctidforsomeorganization"
    ],
    "ceterms:verifiedClaimType": [
        {
            "@type": "ceterms:CredentialAlignmentObject",
            "ceterms:targetNode": "claimType:BadgeClaim"
        }
    ]
}

{
    "@id": "res:cert",
    "@type": "ceterms:Certification",
    "ceterms:ctid": "ghijkl",
    "ceterms:offeredBy": [
        "res:ctidforsomeorganization"
    ],
    "ceterms:image": "https://...",
    "ceterms:name": { "en": "CompTIA Certification" },
    "ceterms:usesVerificationService": [
        "res:vsp"
    ],
    "ceterms:hasVerifiableRepresentation": "res:badge"
}

{
    "@id": "res:badge",
    "@type": "ceterms:DigitalBadge",
    "ceterms:ctid": "mnopqr",
    "ceterms:offeredBy": [
        "res:ctidforsomeorganization"
    ],
    "ceterms:image": "https://...",
    "ceterms:name": { "en": "CompTIA Certification Badge" }
}

What actual, tangible value is added by the third object in the list of objects in the JSON-LD below?

It puts information in the registry about what you should do if someone turns up claiming to have Certification ghijkl

Does that value outweigh the overhead incurred by requiring publishers to publish, maintain, update, etc., two credentials, two CTIDs, for every credential they have instead of just one?

It is their decision to issue a badge by way of verification

Does that value outweigh the overhead incurred by people searching the registry or the Finder, who will now see a bunch of (to them) duplicate credentials, and not know which one to download/click on?

Both credentials exist. You could make the verification badge a bnode.

Which one's CTID is the canonical CTID for the credential?

The Certification is the main thing

Which CTID would you use for links from other places (e.g. wallets), and why?

The Certification, because that is the achievement.

Which one's Finder page would you link to from those same other places, and why?

The Certification

Won't publishers complain about us doubling their workload (they've complained about far less in the past)?

Is it mandatory? Isn't it their choice?

Shouldn't the Badge reference the Certification, rather than the other way around? Someone consuming the badge will not know what it is a badge for, whereas someone consuming the Certificate shouldn't need the Badge at that point.

The issued badge can reference the Certification as the object of the achievement.

I don't think there should be two separate entities in the Registry to describe the same credential (for an achievement an organization recognizes using an Open Badges issuance process for the purpose of claiming a Certification's criteria has been met). That to me should be one entity, of Type Credential, Subtype Certification that describes the IRI identifier used by the issuer in their Open Badges software and describes that the verification protocol for issued instances of this credential shall be via Open Badges mechanisms. This idea of having a separate ceterms:Certification and ceterms:Badge entities to describe the same linked data BadgeClass (OB 2.0) / Achievement (OB 3.0) doesn't seem to add any value from my perspective.

It puts information in the registry about what you should do if someone turns up claiming to have Certification ghijkl

In practice, when a learner does this with an OpenBadgeCredential (OB 3.0) or Assertion (OB 2.0), they would do it by presenting that issued open badge to the consumer, who can then use the verification method described within that assertion to verify its integrity. There is no capability described by Open Badges for a verifier to go to some common landing page for the issuer and ask the question "Hey, nate@example.com says he has earned Certification ghijkl, is that true?". All verification requests start with the actual OpenBadgeCredential/Assertion data.

After meeting with @ottonomy earlier, we got some very useful insight into how both V2 and V3 badges work, and how that interacts with the proposed modeling.

Based on that, I think the following scenarios are closer to reality:

First, the generic all-CTDL case that we initially discussed accommodating. This would be the case where there is a very simple verification service in the classic sense (ie put someone's name into a text box and get a yes or no as to whether they have a credential). This is just here for comparison to what comes after:

Next, the Open Badge V2 case. @ottonomy correct me if I'm wrong in either this or the next one. Here we have a BadgeClass corresponding to each Certificate, where the BadgeClass uses the 1edtech spec (I have prefixed all the 1edtech stuff with "edtech" to avoid any confusion with CTDL terms) and that data lives outside of the Registry.

The Certificates reference the BadgeClasses with ceterms:sameAs (no need for a new property - @ottonomy emphasized that the BadgeClass is the same thing as what our earlier diagram was trying to describe via ceterms:Badge), and the BadgeClasses reference the Certificates through their alignments.

The verification types in play are (again, according to @ottonomy ) almost entirely made of "HostedBadge" wherein every single individual user's Assertion has a unique URI that can be resolved to verify that user's badge (there is still technically a service - hence "hosted" - but that service doesn't necessarily have any kind of page or frontend or singular endpoint).

Now, the Open Badge V3 case. In terms of the CTDL side, it's even simpler. Technically, the Verification Service Profile isn't even necessary, because there is no service at all (aside from, potentially, a service to indicate the revocation of a user's credential - more on that later). This is because Open Badges V3 uses cryptographic signatures - basically, each individual's AchievementCredential is self-verifying.

However, in order to provide a consistent way to query for "all CTDL credentials which are represented by a badge", it may make sense to have a VSP even for these.

There are some other notions that came up in the course of talking with @ottonomy about all of this.

First, is it necessary to indicate, in CTDL, whether the badge issued to an individual is verified via a single endpoint, an endpoint unique to that individual's badge, or via cryptographic signature (or some other means)?

If so, the best way to do this may be via referencing the badge specification via some URL property on the VSP, e.g. "ceterms:verificationStandard" or "ceterms:verificationProcess" or something along those lines where the value would be a link that describes all the necessary info, such as a link to https://1edtech.github.io/openbadges-specification/ob_v3p0.html. This is more flexible, but maybe less intuitive.
Alternatively, we could create a couple new concepts for verifiedClaimType (keep in mind that that property is multi-value, so we could include claimType:Badge along with a second concept to further refine what "kind" of badge claim). This is a little easier to use in terms of publishing and consuming, but not as flexible or future-proof, and we may struggle with coming up with suitable definitions.

Second, the proposed ceterms:hasVerifiableRepresentation property isn't quite right. @ottonomy pointed out that:

The thing being referenced (BadgeClass (V2)/Achievement (V3)) is describing the same underlying credential as whatever is on the CTDL side (hence the use of ceterms:sameAs in my diagrams above)
It would be completely duplicative and unnecessary to create a ceterms:Badge to sit in the middle (which is what I have been saying for some time, albeit for subtly different reasons) when you could just reference the Open Badge directly
The proposed definition for the property is not quite correct given the way Open Badges work - specifically, the BadgeClass (V2)/Achievement (V3) is not the "inherently verifiable" thing; the Assertion (V2)/AchievementCredential(V3) is. That is another step (or two) removed from the thing being directly referenced by the CTDL credential.

If we want something more specific than ceterms:sameAs, then we'll need to name and define it in such a way that it properly indicates that extra hop (or two) from the thing being referenced to get to the verifiable thing. We could probably keep the property URI and label (otherwise we're probably stuck with something janky like "sameAsVerifiableRepresentation") and work on the definition some more.

If we're linking all things with a badge to a VSP via usesVerificationService, then sameAs is probably fine from a search/query perspective, as you can just look for all things with a value for the usesVerificationService property. If, however, there is ever a case where we would not link to a VSP (as I mentioned earlier, VSPs are arguably unnecessary for V3 badges), then a more specific property would have some value.

Lastly: Revocation. Something @ottonomy brought up that we hadn't considered is the part of verification that says "yes, this is a real badge, and it was issued to that person, but it has since been revoked". This is different from the function of ceterms:RevocationProfile, which is meant to describe how and why something could be revoked (sort of the inverse of ceterms:ConditionProfile), whereas VerificationServiceProfile would be the more correct place to indicate that a particular awarded credential has been revoked. Fortunately, I think this is already covered by the existing properties already on VSP:

verificationDirectory: "Directory of credential holders and their current statuses." (their current status could be "revoked")
verificationService: "Direct access to the verification service." (this service would naturally also indicate that something was revoked)

I don't see a realistic need for something like a "revocationDirectory", nor would such a thing likely exist, so the existing VSP functionality should cover this aspect just fine.

The first two diagrams are exactly right, I think. Good job. As a CTDL consumer, what I would understand this as if I came across it in the Registry is:

There is a credential
of type Certification
that uses an Open Badges verification protocol to issue credentials that learners may present to me.

It's useful to know if a particular CTDL Credential will be issued as an Open Badge (and thus can be verified upon presentation via Open Badges protocols and methods), so it's nice to have this link to a particular verification service profile.

👍 Just knowing that the organization described in the Registry issues Open Badges is a useful and good MVP of a capability to use a VerificationServiceProfile to describe issuing behavior. There are further parameters that this class could carry to serve additional use cases, but you don't need to rush to immediately serve these use cases.

Essentially, as an interested consumer of an organization's credentials, such as an employer who is interested in hiring graduates of the colleges in their region, I would be interested in understanding what options each of these colleges use to issue Open Badges. I want to be able to accept badges from these systems when graduates present them to me without false positives (scam credentials issued by impostors) or false negatives (inability to verify or trust authentic credentials at time of presentation due to not having

Now, the Open Badge V3 case. In terms of the CTDL side, it's even simpler. Technically, the Verification Service Profile isn't even necessary, because there is no service at all (aside from, potentially, a service to indicate the revocation of a user's credential - more on that later). This is because Open Badges V3 uses cryptographic signatures - basically, each individual's AchievementCredential is self-verifying.

As a Registry consumer, I would equally (or even more) want to see a VerificationServiceProfile associated with the Credential, and the Organization that offers this credential. You're right that issued badge Assertions/OpenBadgeCredentials self-describe their verification protocol, making it seem like we might not benefit from describing further at the Issuer/Organization or Achievement/BadgeClass/Credential level . In both OB 2.0 and OB 3.0, the verifier starts the verification process by being presented an Assertion/OpenBadgeCredential by a holder. But there are some questions about how this issuer issues verifiable instances of these achievements that I would have prior to receiving a specific issued credential to evaluate.

What type of digital signature (VC proof method) does this issuer use? (Do they use methods compatible with my system?)
What public keys are associated with credentials they issue, and what is the status of the usage of those keys?
What issuer identifier(s) are used within VerifiableCredentials issued by this issuer. (Is did:web:bestbadges.net:org:exampleu.edu an authentic issuer profile used by the organization described in the registry?)
What, if any, revocation checking service is there for OB 3.0 credentials issued by this organization?

Also, even more broadly, there are huge use cases the Credential Registry (or another such registry that uses CTDL to describe organizations) might serve for describing why an issuer in the registry might be trusted by verifiers.

Do any other organizations trust that a particular set of verification parameters are accurate?

If so, the best way to do this may be via referencing the badge specification via some URL property on the VSP, e.g. "ceterms:verificationStandard" or "ceterms:verificationProcess" or something along those lines where the value would be a link that describes all the necessary info, such as a link to https://1edtech.github.io/openbadges-specification/ob_v3p0.html.

I don't know what the ideal IRI or term would be here in terms of CTDL style, but as long as there's a unique and precise string for each OB 2.0, and OB 3.0, or even just some single unique term that encompasses them both, that would be fine with me. For example:

A canonical link to the OB 3.0 spec is https://www.imsglobal.org/spec/ob/v3p0/
A canonical link to the OB 2.0 spec is https://www.imsglobal.org/spec/ob/v2p0/
A specific identifier for the hosted 2.0 verification scheme is https://w3id.org/openbadges#HostedBadge
A specific identifier for the type of OB 3.0 credential is https://purl.imsglobal.org/spec/vc/ob/vocab.html#OpenBadgeCredential

yes, the diagram above is enough to say that a Credential is verified via an issued badge. We should implement that much.

but as long as there's a unique and precise string for each OB 2.0, and OB 3.0

Yep, if you want to say which type of badge is issued you need an identifier for the specific badge that is issued. It is certainly not the identifier of spec or the scheme (they are totally different things). The OB 3.0 identifier would be OK, if that is specific enough, i.e. if it is not going to lead to anyone saying "but I have dozens of open badges, which one do you want me to present for verification?".

The items from this post have been implemented in CTDL and noted in the history tracking.

CredentialEngine / Schema-Development

Verification Service Profile updates #866