Open Badges 2.0 (Time to Vote)

Background: The Open Badges specification describes a method for packaging information about accomplishments, embedding it into portable image files as digital badges, and establishing an infrastructure for its validation. This data should makes it possible to verify the asserted achievements by identifying the issuer and recipient, explaining the criteria required along with the evidence of the achievement. Open Badges are JSON-LD compatible, making it possible for them to be consumed by applications, APIs, as well as searchable and findable on the web.

Open Badges is currently at V1.1 and movement has started in the direction of 2.0 to address long-standing issues in the badges ecosystem and new innovations. Issues have been compiled and it’s been requested that the community vote on the priority of these issues. The community can vote here: https://docs.google.com/spreadsheets/d/1uDTQeq41BGefaX2XSq8sq-jNTBJDjvR4i2lxXowaiQ0/edit#gid=0

As of this writing only 10 people have voted. I suspect that many members of the vast Open Badges community do not yet understand the implications of these changes. Also, it is very possible that some critical needs are not included (although the issues list is extensive). Below I’ve broken down each of these issues and shared my opinion and how I voted on priority (1 = Low Priority, 2 = Medium Priority, 3 = High Priority, “?” = You don’t understand the issue). Please comment below or join us in the Open Badges Community Google Group with your questions and comments. In the spirit of the election season in the US, let’s get ourselves up-to-speed on the issues and vote!

Identity

Update Recipient Class to allow for expanded identity types (#77)
Verify Authenticity of the Issuer reference in a badge (#78)
Verifying an entity corresponds to a specific Profile (#79)
Update the Identity of a Recipient (#88)
Reference public key in profile instead of assertion (#89)

These issues are directly linked. #77 allows for identifying recipients beyond email addresses (a long-standing issue in badges since email addresses are not permanent identifiers) where #88 allows issuers to update recipients identity. It appears #89 could likely be merged with #77. #78 & #79 fit into this category because they address the verifiability of profiles and all of them should be explored and discussed together.

These issues require much consideration and input from the community and are a high priority. We need to consider the role that recipients play in controlling their identity and how that identity can be verified.

Priority Vote: 3
Level of Difficulty: High

Link profiles across multiple platforms (#83)

This issue seeks to address the challenge of multiple organizations using different platforms to issue badges. This is certainly a problem that should be addressed but possibly addressed by improving upon the issuer profile (adding a public key or some other more universal identifier) so that the profile can be shared amongst issuers. We need some input on this from the various issuing platforms.

Priority Vote: 2
Level of Difficulty: Medium

Criteria

Insert Criteria into a BadgeClass definition (#74)

This is probably one of the most important issues on the table. Like evidence, criteria is a URL. This makes it human readable but not machine readable and unpredictable for consumers. Not only should criteria be embedded in a badge class so that is human and machine readable, it should also be done so according to schema definitions. CTI work should be referenced here.

Priority Vote: 3
Level of Difficulty: High

Evidence

Referencing multiple pieces of evidence and related metadata in Assertions (#84)

In my opinion (told I’m not alone in this), evidence is the most under-utilized aspects of badges and one of the most powerful. Currently badge issuers can provide one url to evidence and until visiting that url, the consumer has no idea what to expect. It could a be a video, photo, test score or a web page that lists many different types of evidence. Not only is evidence restricted to one url, the data of the evidence is essentially unusable in a consistent manner for consumption.

Priority Vote: 3
Level of Difficulty: Low

Data Format

Enforce specific syntax for timestamp (#86)

Agree with this one. Date is an important verifiable aspect of badges. Consumers should be able to expect one format.

Priority Vote: 3
Level of Difficulty: Low

Develop Methods for Version Control and Changes to badgeClasses (#53)

Because badge classes are hosted separately from the assertion, it is very possible for a badge class to be changed after a badge is issued. This poses a problem for consumption and for recipients as there is no record of the change and therefore the badge data being viewed or consumed may not be the badge that was initially issued. This threatens the validity of the badge, particularly hosted badges.

Priority Vote: 3
Level of Difficulty: Medium

Fully Portable Badge Assertions with Embedded BadgeClass and Issuer (#82)

If I understand this issue correctly, it would essentially eliminate the need to separately host badge classes and issuer profiles. As projects like MIT’s Digital Certificates and BadgeChain explore using blockchain and decntralized web technologies to issue badges, the full representation of the data in the assertion aids in that model. It can also be argued that this change could improve upon the verifiability of badges. Incidentally, v0.5 was closer to this approach. The separation of the files was introduced in 1.0. That said, it removes the convenience factor for issuers who are hosting actual json files for badge classes and issuer profiles and wish to reuse them for assertions. Need more clarification. Assigning priority 2 to it in the meantime because verifiability of badges is a critical need and this change as I understand it, would contribute to that but keeping in mind that this would be a breaking change and the implications of that need to be addressed.

Priority Vote: 3
Level of Difficulty: High
Note: Updated from 2 to 3. It’s recommended that this issue be addressed prior to others as it sets some precedence for how other properties may be addressed.

Issuing

Authorizing other Issuers to award Assertions of a BadgeClass (#75)

This issue is well articulated and the scenarios and user stories provide more context. This has been a long-standing request of the community but it begs many questions like: Can others issue badges that I create? What data is needed to prove that others have the authority to issue badges that I create? Do others always need authority (ex: OER scenarios)?

Distinguish between BadgeClass Creator and Assertion Issuer (#51)

This issue should be merged with #75

Priority Vote: 3
Level of Difficulty: High

Endorsement

Issuing a statement of endorsement to a BadgeClass (#73)
Issuing a statement of endorsement to a badgeAssertion (#76)

Not exactly sure what these issues addresses beyond the current endorsement extension. Endorsement is a need for the ecosystem. It adds to the reputation of the issuer and recipient and provides context for the consumer. Not voting on this one for now as not sure it can be addressed adequately within the existing infrastructure. Need more clarification.

Priority Vote: ?
Level of Difficulty: High

Revocation

Revocation document should be linked data (#33)

This issue addresses consistency in data format. Since the rest of badges data is linked data, revocation for signed badges should be as well. Don’t think the priority of the issue is necessarily a dire need but the data format should be consistent. That said, see issues #80 & #87 for more thoughts on revocation generally.

Priority Vote: 2
Level of Difficulty: Low

Verify the expiration and revocation status of the badge (#80)
Revoke a Badge Assertion (#87)

I’m on the fence on these issues which as Nate Otto mentions in #87 are inter-related and probably should be merged. The reality of badges is that if an issuer hosting badges removes the assertion and it is no longer accessible to a consumer and therefore not verifiable, it is as good as revoked. The question is: does a consumer of badges care if it was revoked or just that it is verifiable? If it was revoked purposely, then what is the reason? I’ve honestly yet to hear many dire use cases in the ecosystem beyond being mistakenly issued for revocation except in the case of bad behavior due to the recipient (ex: doctor loses a medical license). Most of the time expiration date is sufficient. Would like to explore use cases in detail vs broad ones in #80 to ensure we’re addressing this to meet the real needs of the ecosystem.

Priority Vote: 2
Level of Difficulty: High

Badge Image

Define Metadata related to the Badge Image (#85)

This issue adds helpful information to the badge image. I would add to this issue encouraging the use of SVG.

Priority Vote: 1
Level of Difficulty: Low

Standards Alignment

Align a Badge to an External Framework, Competency, or Value (#81)

This issue could improve upon the under-utilized standards alignment property of the badge class. This property provides a way to define an array of standards that the criteria of the badge aligns to. There’s room here for improvement for sure. It’s a wide ecosystem issue that goes beyond technical needs. It’s possible to explore this using extensions.

Priority Vote: 1
Level of Difficulty: High

Localization

Defining a Badge Object in Multiple Languages(#1)

This issue was submitted by the original Open Badges developer Brian Brennan (in 2013!). Badges are global. This is an easy win. Do it!

Priority Vote: 3
Level of Difficulty: Low