Issuer-specific Achievements

[ottonomy]

There is a core use case for Open Badges that we should address before we consider this phase of work done, the issuer-specific achievement. We need to propose and verify the effectiveness of a method for an issuer to publish an achievement definition such that it may only be issued by its creator. We started discussing this in #428, but it is right to pull this use case out on its own to address directly.

This is the case for all badges in 2.0, and while 3.0 opens up use cases to be explored for issuers other than the achievement creator, we won't get existing implementers to upgrade to the new version if they can't keep doing the main thing that they have been doing so far in their badges journey.

Here's an example. Most badges in the wild are like this:

name: 5 Star Barista Hero
description: This badge is awarded for the lead curators of the Coffee Stop coffee experience. These are the sensory experts with a flair for customer service and technical precision. Order from a hero's team, and you'll get a damn fine cup of coffee.
issuer: Coffee Stop, Inc.

What we don't want to see is an award of this badge from Joe's Degree Mill Emporium and Discount Barn be displayed as valid in certified conformant systems. But with the major shift from hosted-verification assertions to signed Verifiable Credentials, our mechanisms to ensure that a verifier knows that the VC issuer is the expected one. We can also release 3.0 with the option for badges that may be awarded by any issuers, and later open up use cases for creator-authorized rules that could allow controlled valid issuance by other issuers.

How did this work in 2.0?

There wasn't a separate location in the assertion to declare an issuer, so all assertions of a particular Achievement/BadgeClass could only be made by the issuer, and verifiers would determine if a particular assertion was in scope for that issuer by comparing the assertion to the issuer's verification policy. In 2.0 with HostedAssertion verification, the issuer id had to be an HTTP(s) URI that returned Issuer Profile JSON when requested. Within that canonical JSON, there was an optional VerificationObject that could describe the issuer's policy for Assertion verification URIs that would be considered owned by the issuer. If the VerificationObject was not present, the issuer would be assumed to be following the default verification policy, which allowed hosted assertions on the same domain as the issuer id. If the issuer declared public keys, then signed assertions could be verified to have been produced by one of the keys.

What are our options for 3.0?

I think the options fall into these categories:

1. For badges where a specific issuer must be the issuer of record, the Achievement.id must be an HTTP(s) URI from which achievement JSON may be fetched. The achievement JSON fetched at verification time should be understood to be the up to date canonical representation of the achievement that supersedes a previous version that may appear within a signed AchievementAssertion VC. This JSON should include an issuer property with the same characteristics as the Credential.issuer property.
2. We allow issuers to cryptographically sign the achievement layer independently of the overall VC and bundle that signature into the VC so that we can determine at verification time that the issuer of the achievement is the issuer of the assertion. The achievement may appear at times independently of an issued VC, where verifiers can see that it is a an artifact that was created by the declared issuer.

If the chosen mechanism for issuer locking is not enabled for a particular achievement, that achievement may be considered to be open for any issuer to award, and consuming services should treat awards of this achievement from issuer X as related-but-not-equivalent-to awards of this achievement from issuer Y. The tuple of achievement ID, issuer ID should be considered as the unique identifying information of the achievement.

Then if we desire, at the appropriate time (3.1?), we can get into discussions around authorized-issuing-on-behalf-of-creator use cases, where we could define some different policies like OnlyCreatorMayIssue (default), AnyRecipientOfTheAchievementMayIssue, AnyHolderOfSomeOtherSpecificAchievementMayIssue, TheseSpecificIssuersMayIssue etc.

[kayaelle]

It can be suggested that none of this is necessary because:

1. Creator is an optional field. If it isn't included, then the issuer of the VC is the implied creator
2. With VCs, trust registries exist for these reasons. The bigger question in the VC-EDU space for all edu standards is, what governance is needed? Mostly this has been discussed in the context of higher ed and groups like the Open Recognition can contribute ideas on what governance means for open, non-formal, informal achievements. Creator vs Issuer is an excellent use case for governance discussions at the VC-EDU & CCG level. This is not specific to Open Badges even though this proposal was the first to suggest it.

[ottonomy]

I'm not able to make it to the call today because I'm camping, but bon voyage to Andy! Creating verifiability that the Achievement has been created by a particular entity, and that the issuer is that entity or has been authorized to issue on behalf of that entity are complex things to do. But the verifier-side capabilities to understand these things are pretty important to how open badges have worked historically. We should aim to complete our work on 3.0 soon, and it may be that the workgroups decide to ship candidate final without the ability to tell whether certain forgeries are occurring. If the consumer is looking for a certain Achievement, they would know the achievement id and the expected issuer id already, so part of the Coffee Stop case is solved. It's just that the consumers who didn't have a prior understanding of which issuer to expect for the coffee stop badge won't be able to detect foul play very easily.

I could later propose a signed Achievement and issuing capability rules as an extension if the work group wants to punt on this complex problem as part of 3.0 initial release or something.

Edit: spellcheck'd

[ottonomy]

The co-chairs and workgroup propose punting issuer-specific achievement use cases until after candidate final. I'm fine with this. Maybe to a future version of the spec.

Marty requested I reiterate the follow-on discussion about skills assertions here as well. Long story short, if Achievement is no longer a thing that has a specific creator, then the use case for Skills Assertions could be accomplished using Achievement, rather than using the more complex "Result" structure and jamming the skill information into an AlignmentObject.

From my comment on #428:

(Aside: the Result-based mechanism I described for skills assertions was based on an understanding of Achievement definitions as fundamentally only offer-able by their creator. If that is impossible to enforce or detect because we don't want to trust anything contained within hosted JSON-LD, and VCs issues by others are just as valid as VCs issued by the Achievement creator, an issuer may just want to use an Achievement that directly describes a skill as the mechanism of choice for recognizing that skill. Many issuers could recognize the same Achievement in that case, with achievementType of "Competency".)

[danblickensderfer]

Does "Simplify how Skill Assertions work by reusing the Achievement class #458" resolve #451 (this) or does 451 require anything for Final? @ottonomy