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.

Please see argument in #427

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?"

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?

+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.

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.

@ottonomy does making id optional break your use case?

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.

@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.

@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.

@martyr280 if you think the use cases for "Kalamazoo" or "Melbourne" are straightforward to accomplish for Achievement badges where an id is not included, how would you code the system that would attempt to do that? The only thing I could think of would be something like a "deep equals" check of all properties. And that would fail the "Kalamazoo" case, where the issuer intended to fix an errata level error in the achievement without losing "sameness" with previous typo-laden versions. It's a disservice to the recipients of the badges when their badges through no fault of their own are lacking in these important capabilities.

The only use case achievement assertions without a canonical Achievement identifier are good for is display for humans. What got me excited about Open Badges back in 2012 was that the new badgeclass id in OB 1.0 opened up possibilities for consumption and comparison at scale. I would be sad if we lost those capabilities that all badges since 1.0 have had because we thought it was too hard for compliant issuers to generate a UUID. Is there really a reason not to slap an identifier on one of these things other than perceived difficulty? @kayaelle maybe you could explain to me why a developer who could easily add a UUID to this data would be still motivated not to do it for dinner kind of correctness reason?

In any case, I think we need to do more work next week to determine how to accomplish the "CoffeeStop Customer Service Five Star Barista Hero" case, which Dmitri is correct to say needs more than just an Achievement ID.

@ottonomy my question was does it break the use case, if I implied it makes anything simple or straightforward that was not the intent. I don't have a use case where id is not important, in fact as a system of record, id is critical for not only pathways but longitudinal analysis, reciprocity and it could be argued the validity of registry approaches such as GLIEF. What I do believe is if we want the OB and CLR specs to be the ubiquitous next layer of specificity in verifiable credentials it sounds like id as optional is important. @dmitrizagidulin I believe you had a strong position here and would love for you to weigh in.

@martyr280 thanks for clarifying. I think that it does break the use cases I mentioned to have a badge where achievement.id is missing, or at least make them very much harder, and given that adding a UUID is an effortless one liner in all languages, losing these use cases for so little developer benefit doesn't pass the smell test for me.

If I understand Dmitri correctly, he might just propose we use achievement.type instead for this purpose instead but hasn't quite worked out that suggestion entirely? If that's the case, I believe I can make a case that id indeed is the appropriate property to use here, but I'll turn my focus to the "CoffeeStop" issuer-specific achievement use case for a few days and then loop back around, because achievement.id is likely to play an important role there too, and we'd want to be coordinated.

I feel that achievement.id is the "soul of Open Badges" when it comes to activating machine actionability use cases in the consumer side. Just like with the concept of RSDs that has gotten so many organizations excited and drove OSN membership to over 1000 organizations just one year, the canonical identifier of the thing is what makes a huge amount of interoperability possible. I don't mean any disrespect to people who aren't focused on these use cases, and I'm not trying to be pedantic, they are just very important to me as a developer who wrestled with importing badges and making sense of them at scale in past projects and who will do so again.

If it is decided that the achievement.id is to be required, the following should be considered:

• Hosting the achievement data outside of the VC patently makes the VC less verifiable and portable. This is the issue that has plagued Open Badges for many years and one of the reasons for the alignment to VCs. As we know, hosted data is not as reliable because web servers can be unavailable and data can change without any knowledge of the learner or the verifier (or wallet).

• If there is an achievement.id with a URI that is hosting the data in addition to data in the achievement within the badge, which does the verifier trust? If the URL is unavailable or the data in the VC doesn’t match the data at a hosted URL, what are the instructions for the verifier (or wallet)?

Recommendations with this in mind:

1. Don’t store any json-ld at the achievement.id URI. Instead, host a webpage that isn’t intended to be machine readable.

or

2. If the achievement.id is a URI hosting json-ld data, then other data should not be included in the achievement class. At least with this option, the verifier knows that the web server data, while not 100% reliable, is the data to use. If there is data in the achievement class, then the required id must be in another specified expected format like UUID.

or

3. If there is both an achievement.id URI with hosted JSON-LD AND data properties in the achievement in the badge data (really not recommended), that the specification informs which data the verifier should prioritize (this should be the data in the badge and that the hosted url is for reference only).

Even if it is determined that the achievement.id be optional - the above options should be considered.

Lastly, if one is interested in using hosted data, they could consider not updating. 3.0 is intended to be portable and accessible to the individual throughout their lifetime. 2.0 will continue to be a valid spec just as previous versions are. It seems strange to force centralized notions on intended decentralized implementations when the centralized-based spec continues to be valid. Why bother updating to 3.0 and then not using it to its full potential if it doesn't suit your application?

Hm, maybe I would share my hypothetical approach as a consumer of this data:

Having a mechanism like id to be able to record which achievement was recognized is very important to consumers processing multiple awards over time. I would write the business logic that does this to understand that the data signed in a credential was the data intended at signing time. If two achievements in different VCs from the same issuer use the same id but have some property differences, I will interpret these to be errata-level differences and that the issuer intended to issue the same achievement. If there is a HTTPs id, I may occasionally fetch it and get a potentially canonical or up to date version of what that URL controller thinks is the Achievement, but I won't assume 100% that the URL controller and the VC signer are the same entity with the same intent. I need to build my own "trusted list" of which Achievements I consider controlled by which issuers. Determining which Achievements I should expect from which issuers is not enabled at the spec level at this time.

So that strategy looks most closely like

3. If there is both an achievement.id URI with hosted JSON-LD AND data properties in the achievement in the badge data... that the specification informs which data the verifier should prioritize (this should be the data in the badge and that the hosted url is for reference only)

Why bother updating to 3.0 and then not using it to its full potential if it doesn't suit your application?

For me this is about creating a VC ecosystem where there is enough consistency on schema for defined achievements that consumers will have economic incentive to implement some interesting use cases with that data. I don't want to lose critical consumer side use cases for Open Badges as we make OB available to the VC ecosystem.

But I think we're in agreement that consumers do not need to fetch http URL IDs and that detection of "impostors" issuing achievements defined by others is not possible without building something more complex as described in #451 .

(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".)