Badge Endorsement extension draft

[Nate Otto]

Here's the draft text I worked up to define an endorsement extension. This is the result of months of work and thinking by many peopleThis solves for a limited number of use cases by intent, and is designed to be modified in the future for additional purposes, used as a model for future extensions, and to be complementary to other extensions serving specific purposes. As I wrote this morning, endorsement could be a key factor in enabling the translation of real badge value from an issuer's context to a consumers, so that badges may be turned into real opportunities for earners.


Badge Endorsement:
Any organization that is set up to issue a badge may provide an endorsement of a badge object (Assertion, Badge Class or Issuer). For example, a school district may issue an endorsement to indicate approval of a specific Badge Class corresponding to professional development credits acceptable by the district. See the Badge Alliance Endorsement Working Group framework paper for background.

Endorsement of a Badge Class serves to publicly acknowledge the value of a badge as designed, assessed, and issued by a badge issuer. Endorsements of an Issuer are presumed to apply to all Badge Classes and Assertions created by that Issuer. See the context and schema for endorsement.

Property	Type	Value Description
@context	context IRI	http://standard.openbadges.org/extensions/badgeEndorsement/context.json
@type	type IRI array	["extension", "extension:badgeEndorsement"]
statement	string	The endorser's statement about the endorsement of this particular badge class.
endorsedObject	object	An optional embedded copy of the endorsed Badge Object

Extendable Badge Objects: Assertion

Badge endorsers must create a Badge Class to use for the endorsement, but the extension itself must be added to an Assertion whose recipient identity is the IRI (URL) of the endorsed Badge Object. Endorsers may use one Badge Class for all their endorsements, or they may create multiple badge classes to provide different types of endorsement. Consumers should consider both the Badge Class's description field as well as the Assertion's Endorsement extension'sstatement property.

Example implementation:

BadgeClass:
{
 "id": "http://endorser.org/endorsementclass1"
 "name": "Endorsement",
 "description": "A badge of true endorsement.",
 ...
}

Assertion:

{
 "recipient": {
 "identity": "http://anotherissuer.org/badgeclass5",
 "type": "id",
 "hashed": false
 },
 "badge": "http://endorser.org/endorsementclass1",
 "extension:Endorsement": {
   "@context":"http://standard.openbadges.org/extensions/endorsement/context.json",
   "@type": ["extension", "extension:Endorsement"],
   "statement": "The reason why the endorsed object is worthy."
   "endorsedObject": {
    *** Full copy of endorsed object ***
   }
 },
 ...
}

* context file does not yet exist, but it will be very simple, following the extensions specification.

Feedback from today's Standard WG call:

• The most important technical question was if the approach to using the Badge Object IRI (URL) as the recipient.identity and declaring the type of identity as JSON-LD's '@id' keyword. The resulting assertions are not uploadable to the Mozilla Backpack or other services that expect an email address as the identifier. Only applications specifically written to understand badges issued to other badges will be able to create and read endorsement information.
• My most pressing question was, is this the right information to include so that consumers can understand the endorsement?
• Kerri noted that it might be useful to have a field that would provide a consumer some information about why the endorser is qualified to have a valued endorsement. It is an open question as to what form this information could take, and whether it would be important to be machine readable. 
• I think that linking to a badge assertion or collection of assertions is the eventual answer to questions of authorization or qualification in a manner that could eventually be machine-evaluable. We don't yet have a spec for sharing multiple assertions at once besides the Backpack Displayer API. I don't think we can wait on putting out endorsement as a ready-to-use extension to have a long technical discussion on this topic.
• One of the core ideas behind endorsement is that it builds on trust relationships between consumers and endorsers to create trust between those consumers and issuers. Consumers who already trust a given endorser don't need additional documentation of reasons to trust that entity. Open Badges and endorsement themselves 
• We didn't have time to mention it today, but I think this extension could go hand-in-hand with another "3rd party annotation" extension designed to add properties (like additional alignments) to badges issued by others. The endorsement framework paper indicated a desire to comment on alignment to standards, particularly.
• A lot of feedback focused on how this extension might work with Tim (et al)'s proposal to define a BadgeClass's creator, and create ways for them to authorize different issuers to create assertions. These authorization relationships are very much like endorsement (but I think they also have an explicit authorization purpose and require a little more metadata to define the exact scope of that authorization, like that it may be limited to an explicit set of BadgeClasses. I think that endorsement as defined here could go hand-in-hand with authorization-to-issue-on-my-behalf, but there are many uses for endorsement that do not constitute authorization. 
• A side note: As we met for the #MC4PD Summit last week in Redwood City, a few standard badgers discussed the use cases for authorization-to-issue. It is not explicitly following the 1.x standard, but in a minor update, we could define that the "issuer" pointed to in the Badge Class is the "creator" and assumed issuer, except that an "issuer" property found in the assertion (LD-mapped to obi:issuerorg) could be considered the issuer of the assertion, and the badge could be considered valid if authorization for that issuer to issue the BadgeClass were discoverable.

The next step in this process, before making the extension available for issuers to use, is gathering the Open Badges specification community's feedback on the questions raised by this investigation.

• Are these properties the right information to include in an endorsement?
• Do we need to wait to decide on a method of adding a "qualification-to-endorse" component to the extension, where endorsers can share information about their own trustworthiness relative to the endorsed Badge Object's claims?
• Is the use case of 3rd party endorsement that this extension targets so similar to the authorization-to-issue use case from Tim's investigation that work on endorsement should not proceed until crafting the authorization-to-issue proposal?
• Is this proposal ready to advance as an OBI extension ready for use? (Note: extensions are intended to be an experimental proving ground for new ideas that may later be absorbed into the core OBI specification)

Nate Otto, Developer

concentricsky.com

[Carla Casilli]

Hey Nate,

Thanks for working on this and sharing that effort with the community. A few quick thoughts: we've been talking about Endorsement for a while now and the community is excited to see this in action. Of course we should be cautious about proceeding but we also do not want to get caught in an infinite loop of possible contingency considerations. 

Some quick responses to a few of your bulleted questions:

• Do we need to wait to decide on a method of adding a "qualification-to-endorse" component to the extension, where endorsers can share information about their own trustworthiness relative to the endorsed Badge Object's claims?

• To me this feels a little like the "turtles all the way down" argument. I'd be curious to hear more about how this might work in a streamlined and—in this case—standardized manner

• Is this proposal ready to advance as an OBI extension ready for use? (Note: extensions are intended to be an experimental proving ground for new ideas that may later be absorbed into the core OBI specification)
  

• As I wrote above, fast tracking this effort in a way that is thoughtful but expedited would go a long way toward inviting more people into the open badges ecosystem. 

Again, thanks for the great work. Looking forward to hearing more discussion and seeing next steps.

Carla

[Kerri Lemoie]

Hi & Carla & All,

re: qualification-to-endorse - one simple option we started to explore is adding a uri to the extension that would link to a human readable web page referencing the endorser. This link could be to anything from a website, a blog, about.me, LinkedIn profile, etc… This wouldn’t necessarily be a proof of qualification but it would provide context to the consumer as to who the endorser is. 

Kerri

---
Kerri Lemoie
CTO
Achievery
http://achievery.com
@kayaelle @Achievery100

-- 
You received this message because you are subscribed to the Google Groups "BA Standard Working Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ba-standard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kerri Lemoie]

Hi Andrew,

Great question. Can you provide some detail on how you think the xAPI would handle endorsements?

Our thinking of adding an extension to support badge endorsement to badges is that it adds the context directly inside the badge data.

Thanks,

Kerri

---
Kerri Lemoie
CTO
Achievery
http://achievery.com
@kayaelle @Achievery100

On Feb 5, 2015, at 5:20 AM, Andrew Downes <andrew...@scorm.com> wrote:

Is a badge the right type of "thing" to be asserting endorsement of a badge? Have you considered using Tin Can (xAPI) to handle endorsements? 

--
You received this message because you are subscribed to the Google Groups "OpenBadges" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openbadges+...@googlegroups.com.

[Nate Otto]

On Thursday, February 5, 2015 at 2:20:27 AM UTC-8, Andrew Downes wrote:

Is a badge the right type of "thing" to be asserting endorsement of a badge? Have you considered using Tin Can (xAPI) to handle endorsements? 

Excellent question that cuts to the core of our thinking about why we built this as an OBI extension. We view badges as verifiable statements of trust. Initially, issuers could only make these statements of trust about email address identifiers. Now they can make them about other Badge Objects, allowing us to use the same tools we use to understand badges to understand this new type of relationship, Badge Endorsement. The verification mechanism for Badge Endorsements is the same as it is for other Open Badges, so software built to understand existing badges will likely need little modification in order to understand this kind of endorsement.

I feel that it makes sense to issue these statements as badges because it contributes to our ability to build up trust relationships within a network of people an organizations that are mediated by the same technology. Not all parties that can understand badges have the ability to understand other technologies, like xAPI statements. Further, the identifiers used for entities in the xAPI ecosystem may be different from those used as issuers or earners of Open Badges. This is even a challenge within Open Badges, unfortunately. It absolutely is on my very-important-things-to-work-on list for the OBI to help bring the way identities are constructed for issuers, earners, and consumers together, so that as individuals and organizations, we may fulfill our natural roles as issuers, earners, and consumers of public and private statements of trust.

On the technical viability of using an alternative such as xAPI statements to deliver endorsements: Open Badges are verifiable by dereferencing publicly available URIs. I had thought xAPI statements were only usable when exchanged between parties that already had an established trust statement. Are they also publishable (like Open Badges) so that anyone who views the statement may verify that it was authentically issued by the issuer they expect? A quick skim through the xAPI spec seems to have discussions of authentication only around verifying the identity of a user/system that is talking to the LRS. Is there a method for verifying the authenticity of public statements or of making statements public instead of 1-to-1 transmission between LRSs?

On a side note, I'd like you to make sure to talk to Michael and Mike from http://openbadge.exchange before long to share perspectives on how statements about badges that are not necessarily badges themselves can be constructed.

Nate Otto, Developer

concentricsky.com

[Nate Otto]

All,

As I've thought on this proposal for another week, I've been focusing on the question of "what does a consumer need to know about the endorsement?", using that question to guide what information goes into the endorsement.

Relative to some of the discussions we have been having, here are some possibilities for questions about BadgeClasses that endorsements may be able to answer:

• Do I trust the issuer or endorser to deliver this credential? (Kerri's suggestion of a qualification field may impact the information available to a consumer about trustworthiness of the endorser. Consumers may otherwise rely on their previously-established trust relationships.)
• Does the endorsement provide any additional information about the endorsed credential that helps me understand its value in my context? (I imagine that an "annotation" component of endorsement, potentially packaged as a separate extension could be very useful in "translating" credential value for consumers in specific fields. We haven't yet proposed a mechanism to do this but have discussed potential technical paths for composing badge objects of verifiable authorship into one statement.)
• Does the endorsement constitute authorization to issue Assertions of this Badge Class on the Badge Class creator's behalf? (See discussion led by Tim Cook, Eric Rousselle, and others on this kind of endorsement)
• Does the endorsement signal consumer role acceptance of the endorsed Badge Class by the endorser? (Not yet proposed, but a very useful endorsement signal is one of "I will accept this Badge Class" with a customizable statement of acceptance. The existing proposal has a "statement" field, but perhaps a more formalized "will accept" field would be handy?)

I would love to hear feedback on these four questions, and whether an endorsement extension is an appropriate vehicle to provide answers to consumers who are asking them.

A blog post for background: http://concentricsky.com/blog/2015/jan/currency-your-credentials-3-trust-principles-building-open-badges-software

Nate Otto, Developer

concentricsky.com