Achievement id

[kayaelle]

The id property of the Achievement is required "so it can be the subject of an endorsement." It's suggested that this be changed to optional since not all Achievements will be endorsed and not all issuers should be required to provide a URI for an Achievement. Please note that the VC-EDU recommendation will make this property optional in line with the VC spec.

[justinpitcher]

Other critical stories and use cases exist for id beyond endorsement. The group feels that we should continue to require it for those and the stories we haven't yet thought of.

Suggest we change the language around endorsement to remove the ambiguity.

[kayaelle]

Please see argument in #427

[ottonomy]

From my perspective, the most essential core use case of Open Badges is the "defined achievement" use case:

As an organization that assesses and recognizes achievements, I would like to define and offer a particular achievement, based on criteria of my choosing, and award assertions of this achievement to many recipients who meet these criteria over time.

The entailments of this use case include:

• An inspector is able to distinguish between the achievement creator awarding this achievement, and an impostor attempting to do the same.
• An inspector is comparing two "versions" of awards for a badge to the same individual and is able to determine if they the same badge and if they recognize the same achievement
• An inspector of two different awards is able to determine if the two recipients have earned the same badge or different badges.

It does strike me that we may have let our eyes slip off the ball in recent months if we have not determined exactly how we would ensure the above capabilities can be carried forward from 2.0 to 3.0. I imagined we would propose essentially the same mechanisms as before using Achievement.id, though there may be some disagreement perhaps suggesting that alternative mechanisms would be better. This is something we should address immediately and thoroughly in upcoming meetings.

The sample test can be:
"Harvard University defines its Bachelor's of Computer Science Achievement and confers it to Alice. Bob wasn't admitted to Harvard but pays a degree mill to issue him an assertion of the same Achievement that Alice achieved legitimately. How can an inspector tell the difference between these two awards?"

Another test can be:
"Kalamazoo University defines a Bachelor's of Computer Science Achievement with appropriate criteria and confers it to graduates in June 2022. Then they revise the description to reflect a stylistic change and update the graphical representation (image) of this Achievement and confer it to more graduates in June 2023. How can an inspector tell whether the graduates achieved the same achievement or different achievements?"

A third test could be:
"The University of Melbourne awards two different badges called 'Bachelor's of Science' to recognize participants in different programs. How can an inspector tell whether a recipient of each Achievement credential has achieved the same achievement as the other or separate achievements? How can the inspector differentiate this case from the above case where there were two slightly different variations of the same achievement that nonetheless were considered by the issuer to represent the same achievement?"

[kayaelle]

re Harvard example: Verifiable Credentials are signed by issuers and issuer registries are available to verifiers to ensure that the credential is issued by the organization that claims it is issuing it.

re Kalamazoo - the issuer could choose to include a url or a uuid to demonstrate versioning of the credentials. Also, services like CE/CTDL already keep records of credentials. Or Kalamazoo may not think it matters because of course their degree programs change. The curriculum is available online and the criteria and alignments can contain the relevant info for that credentialSubject. With the id being optional, issuers actually have more options. As the ecosystem grows, new models are sure to arise.

re: University of Melbourne, as with Kalamazoo, the issuer can describe the achievement so that the verifier can consume that data.

All of these present perfectly fine use cases for including an id in an achievement but they do not make the case for it being required. Why force new open badges issuers who are excited about VCs to use old models?

Our eyes did not slip off the ball, Nate. They just see exciting new horizons. Open Badges has more options than ever before and if some issuers have a model or participate in a model in which hosted achievement data or a uuid is necessary then the id is there for them to use. There could be many good reasons for this including endorsements. For those who don't need it why should they be required to take this additional step?

[dmitrizagidulin]

+1, I agree with @kayaelle, and strongly feel that id should be optional (and will recommend VC Edu spec to have it optional).

The use of the id property to fulfill the "defined achievements" use cases described are based on a mis-understanding of the VC mechanism. They are all easily implemented using a combination of type, issuer, and other properties. Compressing all those properties into a single id is an understandable legacy design choice, but not one that should be forced going forward.

[ottonomy]

I agree with Dmitri and Kerri that the "id" alone is not sufficient to address the defined achievement (as issued by its creator and no others) use case.

However, I don't see a significant difference in terms of correctness in terms of using credential.type vs credential.credentialSubject.achievement.id when a verifier is querying for 'holder, please show me that you have earned the "CoffeeStop Customer Service Five Star Barista Hero' badge." (Edit: from the call it sounded like Dmitri was proposing that credential.credentialSubject.achievement.type be used to refer to the identifier of the Achievement that the issuer wished to express. I don't see why type would be better than id for this purpose.)

What I'm concerned about is that we've lost the mechanism to ensure that only the "CoffeeStop" issuer is able to be seen as a valid issuer of a defined achievement called "CoffeeStop Customer Service Five Star Barista Hero". Without an id on Achievement, we have no way to talk about a specific defined achievement that has been defined by a particular issuer, and we also have lost the connection between Achievement and its creator.

Whether or not we use the kind of JSON-LD-native way of defining an identifier for the Achievement entity that has been conferred as Achievement.id or whether the group decides that credential.type should contain an additional type for the specific achievement being conferred, it's important to be able programmatically to answer the questions I asked in my first comment, like "did these two subjects earn the same achievement?". The tuple of issuer.id and achievement.id would be the best canonical way to answer that question to my eye, and only possible if we have both of those ids present.

[martyr280]

@ottonomy does making id optional break your use case?

[ottonomy]

does making id optional break your use case?

First of all, I don't see the benefit of making this property optional. The VC spec has no bearing on whether OB makes this property optional or required, because this part of the claim schema is not in scope for what VC covers. We can extrapolate some conventions that may apply sometimes, but there is no VC rule that says we can't use an ID to represent a concept that is a particular entity of a type in the world, like a particular Achievement definition in a world where there are many such things. And it's very easy for an issuer to generate an ID for an achievement to comply with a requirement that they do so. For example, I just generated the ID urn:uuid:7527c290-9bc5-4b9e-bf22-f101e5b7dd7e.

Second, to your question of the consequences if ID only shows up for some defined achievements but not others. If we make Achievement.id optional (and we did not identify an alternative such as to use Achievement.type for this concept, which to my eye would be less conventional JSON-LD), for any Achievement that does not have an ID, we would return to the "dark ages" of Open Badges 0.5, where it would not be possible for consuming systems to do the use cases I identified above for Kalamazoo or Melbourne.

We have been in this world for years, as there are badges in the wild produced under 0.5 (where there was no ID at this level) living alongside badges produced under 1.0, 1.1 and 2.0 (which required an ID). As the product manager for Badgr, I experienced the challenge of having tens of thousands of extraneous rows in our "Achievements" database table because the ID was missing from some assertions we processed. We had an extra row for each achievement per assertion of that achievement beyond the first where an ID was not included. One real-world limitation that affected us was it was not possible to use these badges on learning pathways (because up to only one assertion would ever match up against a badge requirement there). There were additional problems if users deleted and reimported the badge again, a new row would result. We could not do any machine actionability use cases against these badges.

So, given that it is nearly effortless for issuers to include an ID and because there are large real-world consequences and limitations when there is not an ID that fall upon consuming systems, I think it is not a good balance to strike to say that this is optional.

[kayaelle]

@ottonomy I wish you'd stay away from hyperbole such as: this proposal would result in going to "dark ages". Version 0.5 was a pilot version of Open Badges and in the more than a decade since then the technology and community have evolved substantially.

One clarification, It's true that the VC spec is not aware of the achievement schema but the VC-EDU task force is and that's because you helped to make that decision. The community agreed and this became a key factor in aligning Open Badges & CLR with VCs - a huge win for the entire edu credentialing ecosystem.

I do think many will find the concept of an id useful but still it doesn't make sense to require all issuers to do this because not all edu VCs will need this id. It will be perfectly fine for some cases in edu to issue individually described claims. For example, some may be verified one time only for one specific task.

Maybe consider that the achievements you care most about in the use cases you've provided are the ones that will choose to include an id anyway and are really the achievement descriptions usable in the way you've described.

[martyr280]

@ottonomy thanks for your response. I do see the downside of not having an ID as a badge issuer, which I believe in making it optional the badge issuer could require it, or a badge consumer could require it. From what I read in your response it does not break the use case but does make it difficult for alternative uses of badges such as pathways.