The type property in the OBv3 spec enumerated in B1.28for the Achievement class is noat a require (MUST) field. It should be.

[longpd]

Experience from implementers of the OBv3 who are ingesting these credentials for use in their applications have expressed frustration that many issuers of OBv3 credentials are leaving the achievementType property blank. While there are required (MUST) fields to be OBv3 compliant, such as:

• name
• description
• criteria (for the badge being issued)
• issuer (linked from the AchievementCredential)

achievementType is optional.

Developers seeking to use OBv3 credentials as input to applications that category the assertions awarded, such placing them in a section of a resume that is itself an machine readable structure find doing so hard and usually opt not to use such credentials, preferring to apply AI to the name, description and issuance criteria to extract they type of award the OBv3 assertion is making. This defeats one of the purposes of using carefully design structured data models.

While this property is highly recommended to be used for maximizing interoperability and clarity of the credential, many issuers are deciding not to do so. This has serious repercussions on interoperability and clarity of the credential, especially when it is be machine read and with an algorithm which is trying to use the type property for more nuanced purposes.

Recommendation: Make the achievementType property MANDATORY.

[a-c-brown]

For what it's worth, I think this may constitute a breaking change for OBv3 that would require a Major Semantic Version Update - which is to say OBv4. Could be wrong about that.

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the final release. It MAY also include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.

[robcoyle913]

+1 to making mandatory. Will also need strong guidance and how to fill out that field. Ex: Not just listing it as a Badge if the badges represents a skill or degree.

[ottonomy]

I'm open to making it required in a 3.1 version. But also we could just leave it how it is with slightly better guidance.

In the meantime and potentially forever, I would encourage verifiers to consider Achievement to be the default achievement type if the achievementType property is unspecified. This entry in the enumeration is intended to be generic and equivalent to unspecified or "more specificity is unknown". Its definition is Represents a generic achievement. @longpd would having clearer guidance for verifiers as to what to consider a "default value" solve the problem you're finding in the market?

@a-c-brown I agree that under a strict interpretation of "breaking", such a change might not be allowed in a minor version bump. I hope we can have a slightly loose interpretation of what is a significantly large enough change to require a "major version" bump so that we could do minor schema modifications like adjustments to required or optional properties and changes to enumerations. We will have to discuss the specific limits so that we can stay within them or clearly identify that we are making a major version shift. I suspect that we're more in the territory of needing a minor version bump, but we may discover use cases that justify aob/v4p0.

[longpd]

Nate: the feedback from SmartResume is the vast majority of issuers are leaving Credential Type blank. I'm guessing that the people issuing these credentials are likely not the faculty member or others close enough to the work done for which the decision of which credential Type is most appropriate and can't make the choice. Or whomever is responsible for authorizing the issuance of the credential doesn't have the time/interest enough to do it. Companies adding value to credentials, like SM, therefore can't algorithmically classify the credentials into the resume most section. The credentials are sparsely populated as it is. I don't expect guidance about that issuer should be filling out this field will have much impact and thus will not change the overall frequency of the Type field being completed if it's not mandatory. Phillip D. Long, Ph.D. E: ***@***.*** ——- Founder, RHz Consulting, LLC E: ***@***.*** Charlottesville, VA 22902

…

On Thu, Jan 22, 2026 at 5:03 PM Nate Otto ***@***.***> wrote: *ottonomy* left a comment (1EdTech/openbadges-specification#612) <#612 (comment)> I'm open to making it required in a 3.1 version. But also we could just leave it how it is with slightly better guidance. In the meantime and potentially forever, I would encourage verifiers to consider Achievement to be the default achievement type if the achievementType property is unspecified. This entry in the enumeration <https://www.imsglobal.org/spec/ob/v3p0/#org.1edtech.ob.v3p0.achievementtype.class> is intended to be generic and equivalent to unspecified or "more specificity is unknown". Its definition is Represents a generic achievement. @longpd <https://github.com/longpd> would having clearer guidance for verifiers as to what to consider a "default value" solve the problem you're finding in the market? @a-c-brown <https://github.com/a-c-brown> I agree that under a strict interpretation of "breaking", such a change might not be allowed in a minor version bump. I hope we can have a slightly loose interpretation of what is a significantly large enough change to require a "major version" bump so that we could do minor schema modifications like adjustments to required or optional properties and changes to enumerations. We will have to discuss the specific limits so that we can stay within them or clearly identify that we are making a major version shift. I suspect that we're more in the territory of needing a minor version bump, but we may discover use cases that justify aob/v4p0. — Reply to this email directly, view it on GitHub <#612 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADYBFDJVKFTEZLUG6W7QQT4IFCJHAVCNFSM6AAAAACOYPZ2WOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOOBWHE3TMNBRGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[robcoyle913]

I've heard from Credential Engine the same feedback about credential type. Either blank, or something too generic to have meal meaning to an interpreter. For sure we can increase guidance here. The TrustEd Credential Profile is also looking to make some changes here. Feedback from our Product Steering Committee mtg on Jan 6 was to please avoid any major version bumps until we have larger adoption of Open Badges 3.0. Obviously that doesn't mean to we can't continue gathering use cases, etc, but we don't want to slow down any 3.0 adoption if it becomes known there is a 4.0 on the horizon.