Concentric Sky


Nate Otto // January 18, 2017

Open Badges 2.0 Profiles and Recipient Identifiers Deep Dive

Two students sitting at the computer lab

One of the most intricate sets of use cases defined in the Open Badges 2.0 discovery process was around the definition of an Issuer and a Recipient, in order to improve how badges map to how individuals and organizations construct their identity online and offline. In many ways, email addresses serve as great identifiers. However, people have multiple email addresses. Sometimes they move on from a school or a job, losing access to an address in the process. How can Open Badges allow people to operate within these realities?

Last week, I wrote about how Open Badges 2.0 introduces flexible recipient identifiers and Profiles, and this week, I will focus more directly on the specific motivations and approaches that were accepted into the 2.0 Recommendation. This topic covers a sizable portion of the capabilities proposed for 2.0, where some of the others, like the ability to embed evidence metadata in Assertions are far simpler.

Award badges to and from a Profile (#77)

The first set of capabilities on this topic deals directly with being able to award badges to multiple attributes that identify an entity and to be able to use issuer Profiles to be able to receive badges as well as award them.

  1. As an organization or an individual, I want to define and be identified by a public hosted Profile that includes any number of attributes and to have badges issued to that profile… (#77-1)
  2. As an organization or individual, I want to issue badges to a recipient’s profile that can contain multiple identifiers… (#77-2)
  3. As an organization or an individual, I want to issue badges from my public profile… (#77-3)
  4. As an issuer, I want to define a profile based on any number of attributes for a recipient who has not yet created their own profile on my system… (#77-4)
  5. As an issuer, I would like to award a badge to a recipient based on hashed (obscured) versions of attributes that identify them so that inspectors are not easily able to discover the recipient’s identity, while enabling the badge to be reconciled with public versions of the recipient’s profile. (#77-5)

How did we serve these capabilities in the Open Badges 2.0 Recommendation? The solution starts with the new Profile class. The previously used Issuer class is now considered a subclass of the more general Profile that can be used to represent any actor that uses Open Badges, either as issuer or recipient.

Defining a Profile: In order to be used for issuing, this must be publicly available at a consistent URI (#77-1), though ephemeral instances or Profiles may be generated dynamically within applications to represent users and entities(#77-4). Case #77-3 merely reaffirms the issuer property of the BadgeClass that identifies an issuer Profile as the creator of that badge and issuer of its Assertions with no change from v1.1.

Awarding Badges: Badges are awarded to a particular string identifier (one of the so-called Profile Identifier Properties) that is one of the attributes of a profile (#77-5). Different issuers may know an individual by different email addresses, but if they are both understood to be part of a profile, inspectors can understand badges awarded to each address as belonging to the same individual. Alternately, as requested in #77-2, an issuer may award an Assertion directly to a profile by identifying it’s “id” property as the target.

If the following two emails were trusted to correspond to this profile by a consumer, they could understand badges awarded to either one of them, or to the profile id itself as belonging to this published profile.

  "context": "",
  "id": "",
  "type": "Profile",
  "name": "Steve Exampleton",
  "url": "",
  "email": ["", ""]

Verifying a Profile is Accurate

That brings us to the question of how consumers decide to trust the contents of a profile. Who believes that both these addresses belong to Steve Exampleton, as the above profile claims? This requirement is expressed in issue #79.

  1. As a badge consumer, earner, or issuer, I want to verify that a profile truly corresponds to its stated entity so that I can trust badge claims related to that profile (#79).

There is no global trust authority in the Open Badges ecosystem, though there may be many issuers that you trust. This is a critical difference between badges and some other systems, like DNS, which is based on a broadly shared consensus on the trustworthiness of certain root certificates implemented in the browsers on your machine. Open Badges will only at best have super-providers of trustworthiness organization, though before 2.0, there was no canonical way to communicate information about whom was trusted by who. 2.0 introduces the concept of Endorsement, based on some key vocabulary development work done by contributors to the W3C Verifiable Claims Task Force and Credentials Community Group.

I’ll delve into Endorsement in a different post with specific code examples, but let me briefly point to several more capabilities defined for 2.0 and how the combination of flexible Profiles and Profile Identification Properties with Endorsements can serve each case.

Update the identity of a recipient (#88):

  1. As a recipient of a badge, I want to request that issuers update the identity information on my badge assertions so that I can prove ownership of my badges in perpetuity (#88-1).
  2. As a recipient of a badge, I want to provide evidence of ownership of my badges in perpetuity even if my identity information originally referenced in those badges becomes deprecated (#88-2).
  3. As a badge issuer, I want to update the recipient profile of a previously issued Assertion, so that recipients of my badges can easily use these badges, even if they change email addresses or lose the ability to verify a previously used identifier (#88-3).

The first (#88-1) can be easily served for hosted-verification Assertions by updating recipient information in that hosted representation to point to the new identifier and for signed-verification Assertions by reissuing. However, endorsement opens alternate pathways as well. For example, if the issuer of an Assertion whose recipient identifier is "type": "email", "identity": "" endorses a profile with that address and "", an observer could conclude that a user who could prove their ownership of the new address could also be trusted to correspond to the old address, at least for the issuer in question. This approach would serve #88-3 for any consumers or platforms who could understand my endorsement.

The applicability of endorsement to the second transferability story (#88-2) is a little more direct. If a recipient has an endorsement you trust that verifies multiple identifier properties about them, you can trust badges that are awarded to any of those properties are theirs even if they can no longer, for instance, prove that they have access to a particular old email address.

Link profiles across multiple platforms (#83)

Another category of capabilities touching on profiles, identifiers, and endorsement is a request to.

  1. As an issuer, I want to have all of my issued badges reference a single issuer profile so that I may use multiple badge-issuing applications or switch between platforms (#83-1).
  2. As a consumer or recipient, I want to understand when multiple Assertions are awarded by the same organization or individual, even if that issuer uses multiple platforms (#83-2).

In order to serve the first story without introducing large amounts of new complexity, the verification property now available in Profile allows issuers to set a scope for where hosted assertions should be trusted that may go across origins, by setting a startsWith or allowedOrigins property for hosted Assertions. For signed Assertions, multiple CryptographicKeys may be associated with an issuer Profile as publicKeys, supporting this use case. While I expect these features to be implemented in verification applications at the coming coordinated launch of 2.0 supporting issuers, backpacks, and verifiers, it may be that this feature takes some time to implement in issuers due to a significant increase in complexity.

With this post, we explored part of the Open Badges 2.0 Recommendation drafting process, how capabilities that had been refined and proposed as part of this effort turned into specific changes to the Specification and its accompanying examples.

comments powered by Disqus