Concentric Sky

Menu

Nate Otto // January 11, 2017

Awarding Open Badges with 2.0: Recipient Identifiers

Header to use on spec update blog posts

The v2.0 Open Badges Recommendation was published by the Badge Alliance on December 31. You can check it out on openbadgespec.org. It has a bunch of new features, including:

  • Improved Linked Data / JSON-LD support for increased portability and compatibility with other standards
  • Embedded evidence and criteria
  • More flexible recipient identifiers
  • Endorsement
  • New image metadata for accessibility
  • Internationalization and multi-lingual badges
  • Improved alignment to external frameworks and objectives
  • Security improvements

When I have little blocks of time over the next month, I’ll be highlighting key improvements in a series of blog posts. Any of the above topics would make for a great discussion, but let’s first turn our attention to how Open Badges 2.0 improves the flexibility and power of recipient identifiers in Assertions.

Flexible recipient identifiers in Open Badges 2.0

Open Badges v1.1 nominally supported methods for awarding badges to identifiers other than email, but it was not explicit about how that would be done. The 2.0 recommendation solidifies the method and provides a clearer description of how to identify a recipient by an identifier other than an email address as well as how backpacks and consumers are expected to validate these identifiers.

You would use a block like this in the Assertion to award a badge to an entity identified by url:

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Assertion",
  "recipient": {
    "type": "url",
    "hashed": false,
    "identity": "https://exampleuniversity.edu"
  }
}

That would correspond to the following issuer Profile, because the “url” property matches.

{
  "@context": "https://w3id.org/openbadges/v2",
  "id": "https://badgeplatform.net/issuers/123",
  "type": "Profile",
  "name": "Example University",
  "email": "info@exampleuniversity.edu",
  "url": "https://exampleuniversity.edu"
}

2.0 does not require recipients to publish Profiles, as they can be identified in Assertions by their constituent properties, like their email address. However, I think many backpack platforms (or more generally, any platforms that have user accounts for badge recipients) will take advantage of the more flexible Profile class and indeed publish profiles for their recipients. This could allow recipients to do things like endorse and issue badges themselves. Perhaps more importantly, the Profile class is a standard method to publish a description of an actor in the Open Badges ecosystem (issuer or recipient) with multiple properties, instead of only understanding users as a single email address identifier.

Awarding a badge to a Profile directly

It is also possible with 2.0 to issue directly to a Profile, not by identifying one of its string-identifier properties (email, url, telephone…), but by awarding to the “id” . The “id”, an alias for the JSON-LD keyword “@id”, is the canonical IRI/URI that identifies a particular published instance of an entity’s profile.

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Assertion",
  "recipient": {
    "type": "id",
    "hashed": false,
    "identity": "https://badgeplatform.net/issuers/123"
  }
}

We’ll see if implementers prefer to be explicit like this or not. I expect them to continue to use properties most of the time.

The advantage of identifying a recipient entity via an identifier property is that the recipient can have accounts on multiple systems that can be connected if viewers trust each profile. A badge could be understood to be received by either profile that is trusted to contain the recipient identifier property.

The advantage of identifying via profile id is that the issuer may be very explicit what should be regarded as the recipient entity. Though, this may be slightly vulnerable to manipulation, if the entity hosting the profile changes its value after the badge is awarded but before consumers process it.

Why this matters

The flexibility to award badges to recipient identifiers other than an email address, and to understand entities as having potentially multiple email addresses and other types of identifiers, allows us to better map the badges ecosystem to how the world works for badge users. People and organizations are known in their different circles by different identifiers, but at times, they want to present their credentials together. 

Open Badges 2.0 recipient identifiers allow you to recognize the people and organizations in your life. You can identify them with their:

  • email address
  • telephone number
  • url — a homepage or a social media profile like “https://twitter.com/ottonomy”.
  • profile id

And then anyone who understands the recipient’s profile as a collection of verified properties that describe them can understand the badges they have earned from many issuers who know them by their various names. 

The foundation for these possibilities is written into the 2.0 Recommendation, but their success depends on great implementations for issuing, validation, and backpack workflows created by the companies and developers investing in the Open Badges ecosystem.