Endorsement Search Use Cases

[dlampson]

In yesterday's Endorsement team call, I promised Sunny that I would cull some endorsement "search" use cases and post them here.  So here they are, in a persona form since I couldn't easily extract the more detailed use case text in a public way.  Note that search is still likely in need of definition here.  And it's also possible that some of these use functional needs could be handled via application-side serial scanning vs. a service-side search.  But hopefully this at least helps focus the discussion a bit.  And because I'm new to this WG, I'm also mindful I may have missed prior discussion that would render some/all of this moot--if that's the case, just call it out :-)

Case #1
Emily is an employee at Health Service International (HSI).  HSI pays 50% of the cost associated with professional development (PD) provided that the employee provides evidence of learning from a trusted 3rd party source and receives supervisor approval in advance.  One option HSI accepts for such evidence is any badge that is endorsed by the Healthcare Education Alliance (HEA), and industry association that provides a rating PD service providers and individual learning tools.  Emily uses a search feature on the HSI EPD website to find a list of badges that are endorsed by HEA.  See finds a badge named Palliative Care Communications, which is issued by Horizon Learning and is also endorsed by HEA.  She thinks her job effectiveness would be improved by more knowledge of this subject, and she would feel less stress in some of her interactions with family members during her in-home visits.  She selects this learning product and the EPD dispatches an approval request to Megan, Emily's supervisor, who promptly approves it.  The EPD then notifies Emily that she is free to start, and provides a link to the learning product on Horizon Learning's website.

Case #2
Jonathan is the member services director at Healthcare Education Alliance (HEA).  He is working on a new service awareness update for the monthly HEA member newsletter.  This month is the first year anniversary of the HEA Badge Endorsement Program (BEP).   Jonathan wants to include a chart showing how many badges endorsed by HEA have been issued each month, as well as the number of badges that are HEA endorsed, and the number of badge issuers behind these badges.  Jonathan feels that communicating this information to the HEA members will help build support for expanding the BEP in the coming year--something which he is personally and professionally very interested in making happen.  He also believes that HEA members are deriving considerable tangible and intangible value from the BEP, and he wants to encourage members to discuss this value on the HEA community site.  To this end, Jonathan blogs about value options he's heard members mention in conversations, and encourages others to add their thoughts to the blog discussion.  He also tweets the blog reference to his 12,302 followers and tags the BEP grow chart.

Case #3
Jeremy is a recruiter at HSI.  He is working on an early-stage sourcing project aimed at finding 10 qualified candidates for HSI's North Atlanta team.  He has access to a national database of over 1 million active job seekers.  This database includes references to Open Badges issued to job seekers listed in the database.  He also has access to a sophisticated sourcing system that allows him to filter job seeker profiles based on badge characteristics.  So far, his profile filters have narrowed the qualifying candidates to 1,322, which is still way to many for him to manually review.  So he adds an endorsement filter to only show badges endorsed by HEA and/or Northstar Ratings, another cross-industry badge/issuer endorser HSI trusts.  Now Jeremy sees that the qualifying candidate list has been reduced to 42.  Jeremy decides to start the next sourcing phase using this list of candidates.

Case #4
Melinda manages the HSI professional development program as one of her HR responsibilities.  She just finished reading an HEA blog by Jonathan, which extolled the virtues of the HEA Badge Endorsement Program (BEP).  Melinda wonders how HSI employees PD choices are influenced by HEA's BEP.  She has access to an HR EPD Management feature that enables her to quickly chart by month the badges issued to HSI employees.  She remembers that there's also an Endorsement filter option on this charting tool.  Melinda is able to quickly filter issued badges to only those endorsed by HEA.  She notices that not only has the number of HEA endorsed badges been increasing in 11 of the past 12 months, but also that the ratio of HEA endorsed badges to total badges earned by HSI employees has also increased from 2% in the first month to over 24% in the most recent month.  Melinda feels that this confirms that the HR team's goal of using endorsements to steer staff to seek out quality learning providers is working.

[Kerri Lemoie]

Hi Dale,

Thanks for writing up these helpful personas. 

I'm Chair of the Directory working group. I can fill you in on how search could work initially.

We're tidying up and preparing to release a prototype of an Open Badges Directory to the community. The Directory prototype is currently intended to index all keys in Badge Classes. The Standards working group is exploring adding extensions to badges. Extensions will make it possible for Endorsements to be added to both the class and assertion data as well as other data like locations, target age, apply links - really anything.  This data will get added to the Directory just like any other information in classes.

In the first release of the Directory prototype, issuers will register a list of their badge classes. The directory has an API to allow search on any of the indexed keys including endorsements, name, issuer, tags, etc... 

What we've begun talking about in the Directory working group is how assertions could also get added. Also, other ways of populating the Directory that are beyond just being provided by issuers. We have a ways to go before we get there but the conversations are happening. We'll stay in the loop and keep this group updated.

Thanks!

Kerri

P.S. We have a Directory panel proposed for SXSW EDU. Please vote! http://panelpicker.sxsw.com/vote/39087

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

--
You received this message because you are subscribed to the Google Groups "BA Endorsement Working Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ba-endorsemen...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ba-endorsement/9a34867d-0e36-432a-8f60-e6f4bfa542b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sunny Lee]

Dale, 

Piling on top of Kerri to add thanks to writing up these use cases. It's super helpful to read through and digest these. 

To connect up each of the use cases with the work that Kerri and the Directory wg team is undertaking, I believe, use cases #1, 2 and 4 are made possible through badge class indexing which is currently in the works. 

For #3, the directory will have to sort through the details of indexing specific badge assertions as well but as Kerri mentions, those conversations have begun. 

Looking forward to continued collaboration among the working groups. 

Cheers, 

Sunny

---

From: "Kerri Lemoie" <ke...@achievery.com>
To: ba-endo...@googlegroups.com
Sent: Thursday, August 14, 2014 9:41:36 AM
Subject: Re: [ba-endorsement] Endorsement Search Use Cases

To view this discussion on the web visit https://groups.google.com/d/msgid/ba-endorsement/CF3998C9-AF89-4FDA-BD1F-3627E8D195A0%40achievery.com.

[Nate Otto]

Dale,

Thanks for writing these up. As comments are starting to generate in my mind, I'll write them inline.

On Thursday, August 14, 2014 1:38:30 PM UTC+3, dlampson wrote:

In yesterday's Endorsement team call, I promised Sunny that I would cull some endorsement "search" use cases and post them here.  So here they are, in a persona form since I couldn't easily extract the more detailed use case text in a public way.  Note that search is still likely in need of definition here.  And it's also possible that some of these use functional needs could be handled via application-side serial scanning vs. a service-side search.  But hopefully this at least helps focus the discussion a bit.  And because I'm new to this WG, I'm also mindful I may have missed prior discussion that would render some/all of this moot--if that's the case, just call it out :-) 

Case #1
Emily is an employee at Health Service International (HSI).  HSI pays 50% of the cost associated with professional development (PD) provided that the employee provides evidence of learning from a trusted 3rd party source and receives supervisor approval in advance.  One option HSI accepts for such evidence is any badge that is endorsed by the Healthcare Education Alliance (HEA), and industry association that provides a rating PD service providers and individual learning tools.  Emily uses a search feature on the HSI EPD website to find a list of badges that are endorsed by HEA.  See finds a badge named Palliative Care Communications, which is issued by Horizon Learning and is also endorsed by HEA.  She thinks her job effectiveness would be improved by more knowledge of this subject, and she would feel less stress in some of her interactions with family members during her in-home visits.  She selects this learning product and the EPD dispatches an approval request to Megan, Emily's supervisor, who promptly approves it.  The EPD then notifies Emily that she is free to start, and provides a link to the learning product on Horizon Learning's website.

In what ways could HEA provide a list to Emily of all the badges it endorses? You're probably right that some kind of indexed search service (endorsement-aware directory of badges) would be a good intermediary here. +1

 

Case #2
Jonathan is the member services director at Healthcare Education Alliance (HEA).  He is working on a new service awareness update for the monthly HEA member newsletter.  This month is the first year anniversary of the HEA Badge Endorsement Program (BEP).   Jonathan wants to include a chart showing how many badges endorsed by HEA have been issued each month, as well as the number of badges that are HEA endorsed, and the number of badge issuers behind these badges.  Jonathan feels that communicating this information to the HEA members will help build support for expanding the BEP in the coming year--something which he is personally and professionally very interested in making happen.  He also believes that HEA members are deriving considerable tangible and intangible value from the BEP, and he wants to encourage members to discuss this value on the HEA community site.  To this end, Jonathan blogs about value options he's heard members mention in conversations, and encourages others to add their thoughts to the blog discussion.  He also tweets the blog reference to his 12,302 followers and tags the BEP grow chart.

The number of badge assertions issued for a certain Badge Class is generally not a piece of information that issuers publish. This would require new norms among all the issuers HEA has endorsed. Jonathan might be able to access this information by directly interviewing the issuers involved, but I disagree with Sunny that this user story would be made possible just by indexing Badge Classes. 

 

Case #3
Jeremy is a recruiter at HSI.  He is working on an early-stage sourcing project aimed at finding 10 qualified candidates for HSI's North Atlanta team.  He has access to a national database of over 1 million active job seekers.  This database includes references to Open Badges issued to job seekers listed in the database.  He also has access to a sophisticated sourcing system that allows him to filter job seeker profiles based on badge characteristics.  So far, his profile filters have narrowed the qualifying candidates to 1,322, which is still way to many for him to manually review.  So he adds an endorsement filter to only show badges endorsed by HEA and/or Northstar Ratings, another cross-industry badge/issuer endorser HSI trusts.  Now Jeremy sees that the qualifying candidate list has been reduced to 42.  Jeremy decides to start the next sourcing phase using this list of candidates.

In this example, I imagine the job seekers themselves chose to upload the badges into the system? (You said they're "active" job seekers, so that would probably make sense.) Self-uploading/sharing backpack collections/etc would probably be the cleanest way to make this happen and would make for a good job seeker directory product, I think. +1

Kerri and Sunny: I think that ethically, the presentation of job candidates often makes the most sense to treat this way, with those candidates choosing what resources they would like to share to position themselves before different audiences. It may make sense to have some systems that collect public or private information about those candidates as well -- certainly recruiters would try to gain whatever informational advantage they have by accessing less public information. I think we've done a pretty good job setting norms in the Open Badges community that sharing badges is something under earners' control, and there are risks to weakening that norm. The Internet is a powerful powerful tool for bullying and/or shaming. Imagine if this hypothetical database indexed an anonymous gossip app like Secret that were equipped to let people issue badges of shame anonymously. Those badges wouldn't get many endorsements above-board, but if they got drawn into a database out of candidates' control, they might be something that recruiters would take as a data point against certain candidates before even meeting them. Of course, in the case Dale outlines, his endorsement filters would specifically help to exclude these hypothetical shame badges, so endorsement is a good feature in this scare scenario. 

 

Case #4
Melinda manages the HSI professional development program as one of her HR responsibilities.  She just finished reading an HEA blog by Jonathan, which extolled the virtues of the HEA Badge Endorsement Program (BEP).  Melinda wonders how HSI employees PD choices are influenced by HEA's BEP.  She has access to an HR EPD Management feature that enables her to quickly chart by month the badges issued to HSI employees.  She remembers that there's also an Endorsement filter option on this charting tool.  Melinda is able to quickly filter issued badges to only those endorsed by HEA.  She notices that not only has the number of HEA endorsed badges been increasing in 11 of the past 12 months, but also that the ratio of HEA endorsed badges to total badges earned by HSI employees has also increased from 2% in the first month to over 24% in the most recent month.  Melinda feels that this confirms that the HR team's goal of using endorsements to steer staff to seek out quality learning providers is working.

Presumably the earners have more of an incentive to share badges into the HR system that they know HR will accept, so Melinda's data might be less reliable for these questions than she thinks. However, perhaps HSI has made it clear to employees that there will still be some benefit to taking part in learning experiences that aren't HEA-endorsed. Overall, the badges employees will share into the HR system will bias toward the ones those employees know that HR will value (in addition to the effect Melinda is trying to measure where employees bias toward valued learning experiences themselves).

Dale, I really like the way you think about how endorsement information will be consumed, and the types of use cases these different parties would want to access. I think the software that could support this kind of higher-level understanding of the content of badges is what really shows off the potential of the OBI as a whole. It's the sort of thing I want to be working on.

Nate

[Serge Ravet]

Dale,

Great use cases eliciting the power of searching badges metadata. I would suggest one possible variation: there should be no need for the potential candidates to register on any HR/employment system, but to simply authorise trusted services to access their BP/PDS (backpack/personal data store).

So, in Case #3, Jeremy would use "Open Employment Search" (OES) a trusted service that guaranties that no personal information is ever leaked to the other users of this service. How does it work? Jeremy posts a query to OES looking for  a particular profile. OES returns the number of hits after searching many BP/PDS - no direct link to the prospective candidates is provided to Jeremy. After refining his search to a reasonable number, Jeremy tells OES to send a message to all the short-listed candidates. Each of the short-listed candidates then decides to respond whether they are interested to pursue or not. It is at this stage that a direct, yet anonymous, communication link is provided — this would be important, at least in France, considering the racism prevalent in certain employment sectors. There is no need to provide the real identity as OBI guarantees that the person claiming the badge is the actual holder.

In order to avoid an overload of job offers, people would simply post a statute in their BP/PDS (just like on Facebook) indicating whether they are interested to receive job offers or not (actively searching, have a job but looking for a better one, love my job, but you can tempt me,; full-time, part-time, in my actual region, ready to move, etc.) and the characteristics of the jobs they might consider. It is when authorising OES to access they BP/PDS that people define their employment profile(s) — one can have multiple profiles, looking for gigs as musician, social involvement as citizen and accountant and programmer for main sources of revenue.

OES could also be used for the self-employed (the employers of the self-employed are their clients!): 

"A majority (58%) of EU respondents would prefer to work as an employee; 37% would rather be self-employed. Self-employment has become a less attractive prospect than it was in 2009: then, 45% said they would rather be self-employed." 

Source: ENTREPRENEURSHIP IN THE EU AND BEYOND, 2012 Eurobarometer Survey on Entrepreneurship. http://ec.europa.eu/enterprise/policies/sme/facts-figures-analysis/eurobarometer/

The "endorsement search" is part of OES. It works both ways: find endorsed badges and show who has endorsed a (series of) badge(s) in a BP/PDS. Each OB class has a unique universal ID (UUID). An endorsement badge is delivered by the endorser to the badge issuer (or from a badge consumer to a badge holder, or from a badge holder to a badge issuer, whatever). OES keeps an index of all the "endorsement badges", and uses this information during a search to either search badges with the right UUID (to find all the badges issued with a particular endorsement), or to display the all the endorsers of the badges contained in a particular BP/PDS.

This leads me to one general comment on Dale's cases: they do not leave place for discovering what we don't know. They work by successive refinement, while it is sometimes extremely useful to expand a search to refocus it on a point that was neglected at the first place.

For example, by showing that a number of the candidates searched for a particular badge also share similar badges or endorsers, this information could be used to either restrict or enlarge the search (I would like to show all the potential candidates that have this badge from this endorser and/or have at least one badge from this other endorser). For example, a professional could have the endorsement of many of her peers, which could be a much more valuable information than having one particular badge endorsed by one particular organisation.

In the search of candidates, we should go beyond the literal information contained in badges, the metadata. Metadata is not just a piece of information, it is a connector: it connects ideas, people, places, events, etc. So we could have a search based on the social networks generated by the trust networks established through badges: starting from a recognised professional, find all the other professionals (across the world) that are connected to her through badges. Or when one gets the results of the first global search, which might not be linked to a specific badge (I would like to find a nurse who has a experience in post traumatic practice — there might be 300 and more related badges at some point in the future) and study the social network map of the candidates, elicit those with highest recognition (endorsement) by their peers, etc.

@Nate

The Internet is a powerful powerful tool for bullying and/or shaming. Imagine if this hypothetical database indexed an anonymous gossip app like Secret that were equipped to let people issue badges of shame anonymously. Those badges wouldn't get many endorsements above-board, but if they got drawn into a database out of candidates' control, they might be something that recruiters would take as a data point against certain candidates before even meeting them.

While badge holder anonymity is an integral part of OBI, I don't think that there is room for issuer anonymity — at the first iteration at least, as we could have strong pseudonimity based on social links, but that's another story.

As someone has to accept a badge, why would anyone accept a Badge of Shame? A possible scenario for "shaming" would be for the gossiper to create a fictitious character and post there his Badges of Shame. A superficial analysis of the social network of this fictitious character should demonstrate that there is no connection with the 'real' one, and that the devious character issuing Badges of Shame also has an inexistent or poor social network (in the OBI sense) and is simply a Troll — and being a Troll in the OBI should be difficult as it would have to create many fictitious characters to hold his Badges of Shame. 

So, unless I missed a point, I don't see how potential candidates could actually suffer from ill-intentioned individuals within the current OBI.

On the other hand, it would be useful to report abuses or incompetence. I imagine that this should go through the organisation/people that have delivered a badge/endorsement, or establish some kind of escalation procedure:

1) report dissatisfaction to the badge holder

2) if not satisfied with the response, escalade to one or more of the badge issuers

3) if not satisfied, escalade to one or more of the badge endorsers

(2 & 3 could be reversed, depending on the context, e.g. when the endorsers are peers).

One can suppose that if a badge issuer/endorser receives too many complaints, the badge/endorsement could be withdrawn. Again, the analysis of the social network and activity of the 'complainer' should elicit whether he is a troll or not.

Badges could be great at supporting Quality Assurance mechanisms!

Serge

--
You received this message because you are subscribed to the Google Groups "BA Endorsement Working Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ba-endorsemen...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ba-endorsement/96b970d6-8d7a-4ae8-a750-28fda161fb25%40googlegroups.com.

[Nate Otto]

Serge, thanks for posting. (And as an aside, your name came up frequently in the conversations I've been having in northern Europe. I haven't had time to call you this week, but I will when I'm back home next week)

One note for now, though I should have more to respond for later.

I don't think we have set up the OBI so that the recipient of a badge has to accept it in order for it to be a valid badge. Even as we are thinking of endorsement, sometimes we come up with use cases where the endorsee doesn't need to accept or re-share it for it to have public value. We don't currently have much of an infrastructure around sharing badges outside of what we have built for earners to share them, but I think it will naturally be developed over time. Anyway, this shaming issue is probably an aside that doesn't need too much further investigation in this thread.

Nate

On Wednesday, August 20, 2014 2:30:53 PM UTC+3, Serge Ravet wrote:

...

[Serge Ravet]

Nate, I understand your point, so there is obviously something I missed. 

This is what I've understood from OBI:

1) anybody can issue a valid badge, including a Badge of Shame, fine, but 

2) until this badge has been accepted and pushed into a backpack, it remains in some kind of limbos state; nobody can know that such a badge has been issued (except for the issuer) until it has been disclosed by the recipient — and in my use case, until the recipient has accepted the visit of a trusted service in her backpack.

Through which mechanism could anybody know that a badge has been issued before it has been accepted by the badge recipient and made public (or given access to the BP/PDS to a trusted service)? Is there a way to query a badge issuer to know which badges have been issued and to whom?

If such a thing is possible, then it would be a serious breach in the trustworthiness of the infrastructure.

Serge

--
You received this message because you are subscribed to the Google Groups "BA Endorsement Working Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ba-endorsemen...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ba-endorsement/fa17d3cf-9f3d-469f-aeb9-40176631f295%40googlegroups.com.

[Sunny Lee]

You are right Serge. The badge would need to be accepted by the earner I believe. 

---

From: "Serge Ravet" <serge...@gmail.com>
To: ba-endo...@googlegroups.com
Sent: Thursday, August 21, 2014 3:14:50 AM

Subject: Re: [ba-endorsement] Endorsement Search Use Cases

To view this discussion on the web visit https://groups.google.com/d/msgid/ba-endorsement/FD051ED2-5DCF-4961-BBD7-F26760373247%40gmail.com.

[Nate Otto]

I don't want to get sidetracked on this too much right now, but you can absolutely publish a valid badge without the earner accepting it. It wouldn't fit in the "backpack" model of badge storage, but it would be a valid badge, and the issuer or others could share it around at will through webpages, email, social networks, anywhere that doesn't enforce an ownership check. 

I don't think this constitutes a serious breach of the infrastructure as it stands, though I would think any backpack or portfolio service would want to enforce the kind of checks.

Nate

[Serge Ravet]

Nate,

I would hate to distract your attention from more serious matters, but I suppose that I'm not the only one under the false impression that the badge earner had full control over how and where badges were made public.

If what you write is accurate, and it certainly is, then we should make it clear that Open Badge earners have an extremely limited control over the visibility of their badges and it is the badge issuer who in fact has full control — the badge earner has control over the spaces she controls, while the badge issuer has control over... the rest of the world!

I consider this issue as an extremely serious matter, something like the last nail in the coffin of the Open Badges symmetry I'm looking for.

From what I discover (astoundingly) through your comment, it is probably not unfair to state that the OBI is a power structure where the issuer has all the powers and very few constraints (no need for a Persona, nor a Backpack), and the badge receiver no power and many constraints (need for a Personal and a Backpack, need to "accept" a badge).

If it is true that a badge can be published without the consent of the recipient, then the process of "acceptation" of a badge could be described at best as a simulacra, if not a mockery — and the explanation provided until now regarding the 'control' of badges earners over their badges need to be revised immediately and clearly elicits that badge earners only have an extremely limited control over the publication of their badges.

***********************************************************

*     WARNING - WARNING - WARNING - WARNING - WARNING     *

*                                                         *

*          An Open Badge has been issued to you           *

*                                                         *

*    Be aware that you have no effective control over     *

*    where and how your badge will be displayed.          *

*    Anybody could display this badge without having to   *

*    ask for your consent first.                          *

*                                                         *

*    If it is a problem for you, ask the issuer to        *

*    destroy that badge immediately.                      *

*                                                         *

***********************************************************

We could provide a slightly different message, but we shouldn't let badge recipients believe that they have control over the display of their badges when they have not.

Concurrently, we should find/allocate the resources work on a fix, but in the meantime, we need to expose that flaw (and the total discrepancy with the current discourse on 'badge earner control'). Not doing so would be not only unethical but throw suspicion on the trustworthiness of the OBI as a whole.

It would be a pity that the Network of Trust we are building together could become the Network of Shame...

Serge

[Serge Ravet]

This is what I read at https://github.com/mozilla/openbadges/wiki/Open-Badges-FAQs:

• Badges give earners control over their online identity, integrating with web channels for building community links, for example via social media.

If badges can be displayed without the consent of earners, then they have no real "control over their online identity." 

The sentence needs to be revised with something like:

• Badges aim at giving earners control over their online identity, HOWEVER, in its current state of development, OBI does not provide earners with the actual means to fully control where and when their badges are being displayed: Badge issuers, as anybody else who can get a copy of a valid badge, can publish it without the prior consent of its earner. We are actively working on a fix!

Serge

Serge Ravet, Europortfolio, ADPIOS

Join us at  ePIC 2015 - Empowering Learners & Citizens - www.epforum.eu

Conference dates will be announced in October 2014 

------------------------------------------------

tel  +33 9 8444 2585
mob  +33 6 0768 6727 

Skype  szerge

Twitter    @szerge

Blog learningfutures.eu

www.europortfolio.org www.iosf.org

------------------------------------------------

[Serge Ravet]

My apologies for being insistent, but what I've recently realised, thanks to Nate, has suddenly transformed the solid ground on which I (wrongly) assumed that Open Badges were built on, into quick sand. And I would be extremely disappointed if the response to my trouble was the handing over of "The Idiots Guide to Quicksand Fun."

The crux of the problem: is the current version of OBI conducive to doing badges to people or with them? I'm afraid that it is more of the former than the later.

Here is a table that reflects my current thoughts.

	Doing to	Doing with	Comment
Badge Signature	A badge assertion is signed by the badge issuer (only).	A badge assertion is signed by both the badge issuer and the badge recipient.	In a doing with model, the recipient should be at the origin of the badge issuing process. The issuer can suggest or invite the recipient to claim a badge, but the actual triggering of the process rests in the hands of the recipient.
Badge Revocation	A badge can be revoked by the badge issuer.	The right to issue valid badges can be revoked by the Open Badge Governance Authority (some kind of ICAN, creation of blacklists, etc.).	In a doing with model, the badge issuer who does not respects the rules of the game is warned, then disciplined and eventual excluded.
Badge Spamming	Anybody can issue valid badges without the consent of the recipients. Automata can create myriad of badges to pollute the OBI and render it ineffective.	Any attempt to publish a badge that is not signed by the recipient revokes the right of the issuer to issue badges and it is excluded of the Network of Trust — and annexed to the Network of Shame!	In a doing with model, only badges signed (or any symmetric means of approval) by both the issuer and the recipient are considered valid.
Badge Shaming	Open Badges can be used for bullying and destroying reputations.	Quality control mechanisms implemented in the OBI allow for reporting questions regarding the validity of a badge instance of badge class	Open Badges can't be used for bullying or destroying reputations as the issuing of badges not approved by the recipient would automatically exclude the issuer from the network of trust.

It might be the right time to reflect on how to move from OBI 1.0 (more conducive to doing to) to OBI 2.0 (more conducive to doing with).

Serge

On 24 Aug 2014, at 22:03, Serge Ravet wrote:

This is what I read at https://github.com/mozilla/openbadges/wiki/Open-Badges-FAQs:

• Badges give earners control over their online identity, integrating with web channels for building community links, for example via social media.

If badges can be displayed without the consent of earners, then they have no real "control over their online identity." 

The sentence needs to be revised with something like:

• Badges aim at giving earners control over their online identity, HOWEVER, in its current state of development, OBI does not provide earners with the actual means to fully control where and when their badges are being displayed: Badge issuers, as anybody else who can get a copy of a valid badge, can publish it without the prior consent of its earner. We are actively working on a fix!

Serge

On 24 Aug 2014, at 21:11, Serge Ravet wrote:

Nate,

I would hate to distract your attention from more serious matters, but I suppose that I'm not the only one under the false impression that the badge earner had full control over how and where badges were made public.

If what you write is accurate, and it certainly is, then we should make it clear that Open Badge earners have an extremely limited control over the visibility of their badges and it is the badge issuer who in fact has full control — the badge earner has control over the spaces she controls, while the badge issuer has control over... the rest of the world!

I consider this issue as an extremely serious matter, something like the last nail in the coffin of the Open Badges symmetry I'm looking for.

From what I discover (astoundingly) through your comment, it is probably not unfair to state that the OBI is a power structure where the issuer has all the powers and very few constraints (no need for a Persona, nor a Backpack), and the badge receiver no power and many constraints (need for a Personal and a Backpack, need to "accept" a badge).

If it is true that a badge can be published without the consent of the recipient, then the process of "acceptation" of a badge could be described at best as a simulacra, if not a mockery — and the explanation provided until now regarding the 'control' of badges earners over their badges need to be revised immediately and clearly elicits that badge earners only have an extremely limited control over the publication of their badges.

***********************************************************

*     WARNING - WARNING - WARNING - WARNING - WARNING     *

*                                                         *

*          An Open Badge has been issued to you           *

*                                                         *

*    Be aware that you have no effective control

To view this discussion on the web visit https://groups.google.com/d/msgid/ba-endorsement/12150E4B-4A01-4543-A862-DFA76D23339B%40mac.com.

[Nate Otto]

Serge, 

I'm swamped today, but I will totally respond to this, from a technical perspective as well. I think learner/earner control is a great value to uphold when we think about Open Badges technology.

Nate

You received this message because you are subscribed to a topic in the Google Groups "BA Endorsement Working Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ba-endorsement/YW8D1rKLOAE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ba-endorsemen...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ba-endorsement/9BC6264F-78F2-4287-961B-83306CD2CBE8%40gmail.com.

[Chris McAvoy]

Serge, you make a bunch of good points, and your table of doing to / doing with is very helpful.

There's a perception that the OBI prevents spam, or libel, or inaccuracies...it doesn't. All it does is allow the inaccurate, libelous or spam "assertions" to be read by a machine. It's easy to make an analogy to email - I can fire up a server right now and write you an email from yourself. I could write an email as you to your employer and resign. I could set up a website that's a character different than your homesite and change the content of the site in a bad way, then work very hard to get that site indexed by Google. HTTP and SMTP (the base infrastructure that allows email) don't prevent those behaviors. What does prevent those behaviors is spam filters, services that detect phishing and warnings about dangerous content. Not to mention legal structures that protect from libel, or newer legislative frameworks like the EU's "right to be forgotten".

We should experiment with additions to the OB standard that allow a person to "accept" their badge (opening up the door to the 'work with' column), but without the proper tooling to understand the standard, it's worthless. Open Badges have come a long way, but we're just barely out of the bootstrap phase of the lifecycle of the OBI. It's important to find these sorts of issues in the infrastructure and find solutions that can be implemented and agreed on by the community. 

Going back to the email example, spam prevention was pretty basic for years, then email providers started to require email senders to add additional fields to their email gateways to make it very difficult to do the sorts of things I described above. If those checks would have been in place from the beginning, no spam email would have ever been sent...but chances are, no emails would have ever been sent. There's a balancing act between generating enough need that the extra burden of checks isn't enough to deter people from playing in the space.

So - in short, good to call this stuff out, but don't let it discourage you, we're pioneers...

Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/ba-endorsement/CAPk0ugm4RqceSxWrLRTTeds4ptM-eHBBPZkwUhh%2B0CKjpAYr%3Dg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Director, Technology

Badge Alliance

W: http://badgealliance.org

B: http://chrismcavoy.org

T: @chmcavoy

G: cmcavoy

[dlampson]

Serge, I have just about the same reaction you do--I think OB needs to take the stance that regardless of who initiates the "badge issuing handshake", the protocol is that no badge gets considered "issued" until there's mutual agreement.  In very raw techie terms, OB should be more like TCP/IP than UDP. 

Seems to me that we could take this one step further, to the metadata layer.  It should not be possible to for "non-handshake participants" to see incomplete work.  The whole point of a public badge infrastructure should be to reflect what has been mutually achieved and agreed to, not all the half-baked stuff that may never see the light of day (or a Backpack).  It would be a bad day (at least in my opinion) should LinkedIn start letting anyone issue me Endorsement Badges :-)  On the other hand, perhaps McAfee would rush forth a new anti-BadgeSpam product.  But why start down this slippery slope in the first place?

@Chris, I get your point about one-step-at-a-time.  But I do wonder why we can't learn from history the n'th time around.  The email spam problem has been a bigger pain for a longer time than many of use would wish precisely because too much infrastructure and use grew up for it to be easily changed. Let's not let that happen with OBI.  And besides, given that we know have history suggesting how **not** to do it (or at least one way of not doing it), can't we learn a bit from history?  There's a saying about that....

DL

[Nate Otto]

Dale & all,

On the point of how earned badges might be formally accepted by an earner (which is only one of the facets to what we've been talking about):

You're probably familiar with the phrase I often repeat, "a badge describes a relationship." There are at least two parties involved in a relationship -- while there is certainly a lot of value in hearing how one of those parties describes it, it's a different ballgame to have an artifact that embodies a description mutually agreed by both parties. It's like the difference between saying "Chris is my employee, see here's a photo of him at the company picnic" and showing someone an signed employment contract. I like Serge's distinction between "doing to" and "doing with", but I think there is value in both approaches. I agree with Serge that our eventual ecosystem goals include building up discernable networks of trust for issuers and with Chris that as we build up these networks, we will also be able to build up the tools to filter badges to more easily ignore those "doing to" badges issued by disreputable parties.

The OBI standard at 1.0 only allows for the first kind of description ("doing to"), that made by the issuer about its relationship with the earner. How could we build out the technology to enable this second kind ("doing with") as well?

I've been throwing some ideas around inside my head on what it would mean to have a badge that was signed by both the issuer and the earner (or would those terms be less meaningful in some of these situations?). I think it would be possible to do this in a few different ways. I think the JSON-LD methods of signing badges we have been looking at support multiple signatures as different named properties (maybe verify.signature, and earner.verify.signature). Or an earner could pre-authorize an issuer for any badges by sending a special sort of endorsement assertion that could be included in each issued badge to that earner. Then, educated consumers would know the badges were authorized. 

An aside: In the Standard WG, we have also considered long-term changes including the ability to obviously and non-destructively mark up a badge assertion after the fact, so that original validation still passes, but it could be clear to consumers that a specific second party has provided updated or additional information about the badge with their own signature. This is not at all possible with the current 1.x specification and I think will require a breaking change but is worth considering for whatever 2.0 turns out to be down the road. We don't have a good technical model of how this would work yet.

None of these approaches solve one of the other problems Serge touched on, the ability for an issuer to share a badge with the public without the earner's consent. A couple of the core values of the OBI are simplicity, and portability of information about achievements. I think that problem may have more to do with the privacy policies of issuing organizations than any technical change we could make to the specification to do something like encrypt the contents of a badge until the earner decrypted it for you. (Though if a system wanted to build functionality like that, they will be able to try it out as an extension). There are some strong reasons to keep the OBI simple though, and anything built into the standard to make badges hard to share without verification procedures through the earner would make it harder for developers to build applications that can understand badges.

A side note: Serge, there already is some protection built into the badge ecosystem that makes it harder to share badges without the earner's consent. Notably, earner identity information is hashed (obfuscated) in the badge, so that if you found a random badge laying on the street, you wouldn't be able to tell who it belonged to. This doesn't help in the situations we described, where earners maliciously share badges without earners' consent, because they could always provide the earner's email address along with the shared badge.

Big issues. Sorry to say I'm going to miss yet another Endorsment call on Wednesday, because I bet it will be some good conversation.

Nate

To view this discussion on the web visit https://groups.google.com/d/msgid/ba-endorsement/0b4f609e-c3e1-42bf-a338-457310f3dcf2%40googlegroups.com.

[Deborah Everhart]

Great discussion guys! I was with Serge in getting seriously concerned until Nate added the point about the badge earner’s identity being encrypted. This means that other than deliberately inappropriate behavior where the issuer discloses earners’ identities, the badge issuance is protected. This also means that directory services can do things like find badges and numbers of earners without intruding on earners’ privacy.

 

I agree that the validation of a badge’s value should rest in the relationships it represents, and an earner should have the right to “validate” a badge by accepting it and choosing how to use it. Future directory services will reveal some of this by telling us where and how badges are being used by earners. And if an issuer has issued x badges but only y have been used by earners, that will be an interesting show of value also.

 

There’s certainly more to talk through on the call Wed. re: how these relationships play out when an endorsement is a type of badge—give that some thought everyone.

 

Also please think about how this fits into our working paper, and help us draft it at http://etherpad.badgealliance.org/Endorsement_Working_Paper

 

Deb
---------------------
Dr. Deborah Everhart
Director of Solutions Strategy
Blackboard Inc.
202-463-4860 x2505

Twitter: @ariadne4444

 

Reimagine Education.

To view this discussion on the web visit https://groups.google.com/d/msgid/ba-endorsement/CAPk0ugneD--k0Z4wpgy4erYtrafcaXcqcTS%3D5zyXp3%2BkoheHrg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error.

[Serge Ravet]

@Chris: I agree with Dale: "why [...] can't learn from history the n'th time around"?. This would be even more important as badges are not just about 'communication' but 'identity.' And don't worry, I'm far from being discouraged as I've total confidence in the ingenuity of the Open Badge community (and you!) to address this issue and find the best possible solution. It should be radically different from an equivalent to spam filters that are useful, today, as a means to address a flaw in the initial design of email protocols. Digital signatures and certificates are probably elements of a solution (BTW I enjoyed reading Mozilla's great resource on certificates https://developer.mozilla.org/en/docs/Introduction_to_Public-Key_Cryptography#Certificates_and_Authentication ;-). We should also look at the properties of social networks to enforce trust —until now, most solutions like certificates, rest on an individualistic representation of the world. So the questions wouldn't be not so much "how to enforce trust in social networks?" than "how to use the properties of social networks to enforce trust?"

This would require to implement something like "badge the badger" (which is the earlier expression we used for "endorsement"), so we move from a topology dominated by a series of disconnected nodes (issuers) connected to more or less terminal leaves (recipients). The current network lacks symmetry to be fully effective as a network.

@Dale: I agree with you, badges should stay in limbos until both parties have agreed on their content. This could include an incomplete badge — for example, I would like to work towards a badge on "Trust Infrastructure Design" (using Open badges!) making it public to show my commitment and get support from experts.

@Nate: your statement is "a badge describes a relationship," mine is "a badge is a criterion- evidence-based trust relationship," or "trust relationship" for short. I know that we agree on the issue of trust, so it's more a question of editorial choice, or style. 

The recognition that the current version of OBI is more on the side of the "doing to" than the "doing with" is critical, not only to address the issue of control of one's identity (in fact personal data, which is rather different) but the very process of 'identity construction' itself: while in the past, identity was mainly externally defined, in today's world, identity is more about the invention of self (which is not easy, especially if you are in a world or an institution that does not provide the conditions for empowerment). If we develop a technology that favours the "doing to" over the "doing with" then we tend to encourage practices reflecting a vision of identity externally defined. So if we are serious about using Open Badges for controlling one's identity construction, not just personal data, then there is no alternative to the "doing with." The "doing to" model is congruent with external control, and it doesn't really matter wether one controls or not the personal data generated during such a process, because it already started out of one's control.

Taking the risk of sounding insistent and redundant: the main issue here is not about finding a patch for better protection of personal data, but about creating the technological conditions for empowering individuals to fully control their identity construction process. A "doing with" model is not an improved "doing to" model, it is a different one —and archeology teaches us that we can re-use existing bricks to create an entirely different architecture.

@Deborah: I'm saddened that learning about the encryption of the badge holder's email was enough to waive off your concerns (just teasing!). The use of email itself is a problem as an identifier (I've experienced it when I received a badge at a different address than the one I use for my backpack, people change address, etc.) and an infrastructure prone to spamming and spoofing needs a proper fix.

Moreover, the problem with "inappropriate behavior" goes far beyond disclosing earners' identity by malicious people, it is most and foremost the use of badges to control people, using badges as doggy biscuits, treating people like pets (c.f. Alfie Kohn). Hence the importance of a "doing with" model to guide the development of badge technologies and practices.

@all: I'm totally thrilled to be part of this (extremely open) community, and fully confident that not only we shall solve problems as they arise but create many more opportunities, far beyond what can be envisioned today.

Serge

On 26 Aug 2014, at 04:53, Deborah Everhart wrote:

Great discussion guys! I was with Serge in getting seriously concerned until Nate added the point about the badge earner’s identity being encrypted. This means that other than deliberately inappropriate behavior where the issuer discloses earners’ identities, the badge issuance is protected. This also means that directory services can do things like find badges and numbers of earners without intruding on earners’ privacy.

 

I agree that the validation of a badge’s value should rest in the relationships it represents, and an earner should have the right to “validate” a badge by accepting it and choosing how to use it. Future directory services will reveal some of this by telling us where and how badges are being used by earners. And if an issuer has issued x badges but only y have been used by earners, that will be an interesting show of value also.

 

There’s certainly more to talk through on the call Wed. re: how these relationships play out when an endorsement is a type of badge—give that some thought everyone.

 

Also please think about how this fits into our working paper, and help us draft it athttp://etherpad.badgealliance.org/Endorsement_Working_Paper

The crux of the problem: is the current version of OBI conducive to doing badges to people orwith them? I'm afraid that it is more of the former than the later.

 

• Badges aim at giving earners control over their online identity, HOWEVER, in its current state of development, OBI does not provide earners with the actual means to fully control where and when their badges are being displayed: Badge issuers, as anybody else who can get a copy of a valid badge, can publish it without the prior consent of its earner.We are actively working on a fix!

Serge

 

Nate,

 

.
For more options, visithttps://groups.google.com/d/optout.

 

 

-- 
You received this message because you are subscribed to the Google Groups "BA Endorsement Working Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ba-endorsemen...@googlegroups.com.
To view this discussion on the web visithttps://groups.google.com/d/msgid/ba-endorsement/FD051ED2-5DCF-4961-BBD7-F26760373247%40gmail.com

.
For more options, visithttps://groups.google.com/d/optout.

 

 

 

--

-- 
You received this message because you are subscribed to the Google Groups "BA Endorsement Working Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ba-endorsemen...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ba-endorsement/F7569DFE5B52DF4DBC3224272C0CE42014B357%40AUSP12DAG0103.P12.hostedmail.local.

[Bryan Mathers]

Apologies in advance for these overly-simplistic thoughts on this excellent conversation, but I think it highlights an obvious tension between our “innovating” brain and our “standardising” brain.

The hunch from our "innovating" brain says: 

"Do what you can to keep it as open and flexible as possible, to encourage as much innovation around the edges as possible, as without the momentum of adoption, we have nothing."

The hunch from our “standardising" brain says:

"Tighten it up as much as possible, because this standard needs to stick and be robust - otherwise we will miss our opportunity"

Both of these are valid. But in my opinion, OBI is still in Startup Phase - so I suggest we lean toward keeping it as flexible as possible. However, there will probably be a time in the not-so-distant future when a pivot is required.

Bryan

Bryan Mathers / Head Honcho
07450 258268 / bryan....@wapisasa.com

wapisasa C.I.C. 
http://wapisasa.com

  

This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorised disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. wapisasa is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.

To view this discussion on the web visit https://groups.google.com/d/msgid/ba-endorsement/10C9AB80-EC0D-443D-8C68-374E46A754A3%40gmail.com.

[Sunny Lee]

sidenote: Endorsement call happening now folks: http://etherpad.badgealliance.org/ba-endorsement-aug27

---

From: "Bryan Mathers" <bryan....@wapisasa.com>
To: "Serge Ravet" <serge...@gmail.com>
Cc: ba-endo...@googlegroups.com, "Deborah Everhart" <Deborah....@blackboard.com>, "Nate Otto" <na...@ottonomy.net>, "dlampson" <dlam...@intraxinc.com>
Sent: Wednesday, August 27, 2014 9:34:16 AM

To view this discussion on the web visit https://groups.google.com/d/msgid/ba-endorsement/0CE89B21-3A07-47D7-8826-C3874F4E2B37%40wapisasa.com.