You can clone with
Some badges might come from one email address, some badges come from others. Just had this pointed out by a friend who received a badge on his UMich email, but wants to tie it to his Gmail based BrowserID backpack. Logging it for a future fix (or maybe it already exists?)
This is what I meant by issue #4, but you said it better.
The idea would be (I think) making the user go through another identity assertion with browserid and having a table which ties together related identities.
At the mean time, if you got a badge with one email but login the backpack with another, you will get a message like "you didn't receive a badge," but might not know that this is due to different email. We might need a helpful error message about it before this issue get fixed.
Sent via Hubroid
This is not explicitly on the roadmap but it's come up multiple times. @threeqube can we move this off the 1.0 list? Or is it a pre-req for something else we consider 1.0?
@cmcavoy not a prereq for v1.0, we can move this into v1.5. Really want to think about the ux around merging backpacks though.
We've come across this issue while working on integrating open badges into Moodle/Totara.
Typically the user wants to maintain control over their backpack, therefore they will create it using a personal email address.
On the other hand, academic or corporate training which will lead to the issuing of badges will typically happen within a private learning management system, where the user has a different email address (their work or university email). Unless users can "attach" their work/uni email to their personal backpack account the backpack won't let them import badges they've earned (because the email addresses don't match).
Typically a user will lose their work/university email when they change jobs or graduate, which will mean the user losing ownership of their badges too.
Unless I've misunderstood how this works I think this is a pretty serious problem that I think will hurt open badges adoption - people will be less likely to want badges if they can't maintain control over them and risk losing them over time.
Would you consider increasing the priority of this issue?
Well, I'm far from convinced that accepting multiple email addresses is the solution to the actual problem. Emails (persona) are used so that badges can be linked to a specific user. Adding more email addresses will only make the badge structure more clumsy and the process of verification more complicated.
One viable alternative to identification would be the use of WebID (http://www.w3.org/wiki/WebID), "a way to uniquely identify a person, company, organisation, or other agent using a URI." A WebID could be associated with many different email addresses, but the verification process would relay on a unique identifier, independent from central authorities, like email providers. And we certainly don't want to encourage the use of providers like gmail if we want to avoid receiving spam emails based on the badges collected...
Moreover, the use of WebID would create a symmetrical distributed network of trust, with no need for specialised backpack hosting providers: everyone could host his/her own backpack and be simultaneously a badge issuer and badge recipient.
I would say that end-user usability should be a key consideration when assessing the complexity of the verification process. Users are already pretty familiar with dealing with multiple email addresses - symmetrical distributed networks, certificates and key pair generation, not so much.
I fully agree with end-user usability considerations. But I don't see why it would not be possible to hide the complexity involved in symmetrical distributed networks to the end user... People use email without having the slightest idea of what a pop, imap or smtp protocol are. Nor do they need to know about the https stack to engage into secure communications.
On the other hand, while email addresses are meaningless, WebID could (but not necessarily) provide information on the class of users; that would be particularly useful when dealing with children. We could compose URIs (WebIDs are URIs) in such a way to keep full anonymity, while being able to provide information that would help the enforcement of policies regarding the exploitation of personal data.
Moreover, instead of having multiple addresses connected to one backpack, it would be much more relevant to have the ability to federate multiple personal backpacks if one needs to keep apart different identities. One might want to keep apart a backpack related to work and education from one related to leisure or healthcare (there will be a presentation at the ePIC conference - http://www.epforum.eu - on the use of open badges for patients with diabetes.
After all, if people have multiple email addresses, it is for a good reason. They might have even better reasons to have multiple backpacks. The decision to have one or multiple backpacks should be left into the hands of the end-user, not in those of the designers.
I'd second adding the ability to use Persona's knowledge of other validated email addresses to allow multiple recipients. When uploading, and recipient and email don't match, query Persona for other validated emails and accept them. Also, showing the recipient field in the interface would be helpful as well.
Assuming an identity formula of one email = one recipient = one identity is simply not the way the world works in either education or work these days (if it ever did.) Over the period of a few years, a student could easily have several school email addresses, then an email address for each of several jobs, then a couple of personal ones as well. I already have badges issued to three of my emails in various apps just this Summer.
As badges accumulate over time, users need a single centralized management point for them all. If a user chooses to have multiple bacpacks, they can always do that by creating multiple Personas. But an important goal of Persona is precisely to avoid the need to do that, as evidenced by the capability to associate and validate secondary email addresses with a single Persona.
@wmrandth Unless I've missed something, Persona only lets the user associate email addresses; there's nowhere in the API for the Backpack to ask Persona if two email addresses belong to the same user. The last I heard, they had explicitly decided against exposing that information through the API so that the user retained full control of their identity online, so I don't see that changing any time soon. It'd be great for us if they chose to tackle that problem, but I'm not sure they will.
@stenington Thanks for the clarification. That must have been the outcome of those authentication vs authorization debates.
Pity -- it would have been an elegant solution for both users and app developers.
Large personal data collection vendors like Facebook and Google will have no hesitation in making this work when they do their own backpacks: all the better to collect collateral email addresses via badges. It just makes it harder for smaller vendors (like Mozilla ;)
Lack of recipient multiple email support is a serious blocker for edu apps for OB for the time being.
Hi, I see that this problem started long time ago.
My problem is that I created a openbadges account before doing an online course, with my e-mail "email@example.com". This is correct, but I saw that I cannot change the e-mail in case of I need to do it.
A page where I did a course with open badges is not able to change the settings of the mail too, but unfortunately they convert all the e-mails with mayuscules, so my mail there is ¡Z@gmail.com!, and this is why I cannot receive the badges :(
Some people created later the openbadge account correcting the error and login in open badge with the mail in mayuscules. But the people that we created before the backpack we cannot receive them
:(. Please solve it as soon as posible. Thank you so much!