Re: [ba-standard] Adding an identity extension to the assertion object

Hi, Sunny, Erin, Jon:

(And CC: W3C Credentials Community Group, because this plays into much of 
the work that has been going on in that community since before it was even 
organized under that name)

I have been wrestling with this idea for the last year and trying to find a 
technically beautiful solution that allows different kinds of identifiers 
and allows people to collect badges issued to any of the of their 
identifiers. It's a tricky problem, because it has to be solved at both the 
standard and the implementation level. 

One cool thing about Open Badges, is that when we find the right way to 
structure something in the technology, its correctness comes from the 
approach reflecting our values about how the world works in some way. 
Identity on the Internet is a thorny tangled thicket touching almost every 
service, even those that aren't quite as closely tied to individuals' 
identities as credentials are. For identity, I think we need to recognize 
that our reasoning about how people use identity online and offline needs 
to form the basis for how we allow them to be identified in badges.

   - People have many facets to their identity, and interact with their 
   communities using differing/overlapping personas. They are constantly 
   negotiating how they establish their identity in each of their roles in 
   their networks of learning, socialization, work, and romance.
   - Their use of different identifiers in different contexts is an 
   expression of this negotiation process.

I think this nets out to some values we should strive to recognize in the 
OBI:

   - Issuers should not be expected to know a "canonical" identifier (i.e. 
   Backpack account email address) for potential earners they know by other 
   identifiers (i.e. Twitter handles or phone numbers)
   - Issuers should be responsible for delivering badges to earners (or 
   notifying them they may accept a badge)
   - Earners and consumers should take responsibility for ensuring the 
   earner "owns" all the identifiers present as recipients in a collection of 
   badges presented to the consumer. Badge-aware software, services, and 
   interested 3rd parties should assist in this process.

I'm excited to have this conversation, and I want to move a successful 
approach into the standard in the next year. (But as we saw with the v1.1 
conversation, it may take significant amounts of research to ensure that we 
arrive at a solution that correctly represents the values we hold. And of 
course, I'm open to pushback to help better define what values and 
consequences of those values need to be represented by the next generation 
of OBI recipient identifiers, better than the quick list I sketched out 
above).

I don't know that an extension is ultimately going to be the right way to 
do this experimentation and research, however, though I would love people 
to step forward and try a few things out. Certainly we could add an 
additional "recipient"-like object that could implement these values, but 
unless we also provide the standard-compliant original recipient object, 
the badges we issue with this extension wouldn't pass the validator, etc. 
Would love to hear more thoughts on how we might move forward with research 
and experimentation.

Cheers,
*Nate Otto, Developer*
concentricsky.com

On Wednesday, December 17, 2014 8:10:47 AM UTC-8, kruithj wrote:
>
>  Hi Everyone:
>
> I've often thought that the backpack should be the place to handle 
> multiple identities - so login to the backpack using an @gmail account, 
> pair it with your phone number, @school account, or whatever else you think 
> is appropriate for that particular collection of badges. That way the 
> identity issue is sidestepped by putting it back on the user (who 
> ultimately should be in control of this sort of thing). I can think of 
> multiple instances where I might want badges to be collected for my 
> "professional" identity which is connected to my work or school e-mail, but 
> maybe more personal badges associated with my personal e-mail. I think that 
> aligns well with Mozilla's ethos. 
>
> There almost certainly will be issues with school IDs as these are often 
> classified as personal data - not to be shared outside the organization. 
> There may be legislation (depending on state/province) that governs how 
> this data is shared, and how it can be shared. 
>
> Jon
>
>
>
> On 2014-12-16, 9:07 PM, Erin Knight wrote:
>  
> Thanks Sunny! This one is really important, especially for things like the 
> cities work, where we're dealing with under 13s, as well as kids with only 
> temporary school emails that many don't even know how to check. 
>
>  I'm super interested to understand more about how extensions might help 
> here and if anyone has been working on this already.
>
>  Couple of additional thoughts:
>  
>    - Phone number seems like one, especially as we think about expanding 
>    into SMS badging, etc.
>    
>     - Also we need to be thinking about the interfaces for how earners 
>    receive notifications and accept badges through these different identities. 
>    Some are more obvious, like Twitter and phone number, but others are less 
>    so, like school ID. 
>
>  
>    - Also, once we can support different types of identifiers, it begs 
>    the question of how we can associate multiple identifiers with the same 
>    person. So a badge issued to my phone number, and another to my student ID 
>    all belong to me and can live in the same Backpack. This might be the 
>    second phase of this issue, since we need to be able to accept different 
>    types first, but throwing it out there. 
>     
> Thanks!
>  -E
>  
> On Tue, Dec 16, 2014 at 8:07 PM, Sunny Lee <three...@gmail.com 
> <javascript:>> wrote: 
>>
>> Hi folks, 
>>
>>  We've made a lot of progress on the extension specification thanks to 
>> all your hard work. We're now starting to explore how we might add an 
>> endorsement extension and location extension but I wondered, what might an 
>> identity extension that attempts to support additional identities beyond 
>> email, look like?
>>
>>  Are there folks in the community that has been exploring the extension 
>> specification to support identities other than email such as twitter handle 
>> or school ID? Are there particular identities you'd like to see added as an 
>> extension? 
>>  
>>  Sunny
>>   -- 
>> 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 <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>  
>
>  -- 
>   Executive Director
>  Badge Alliance
> W: http://badgealliance.org
>  B: http://erinknight.com
>  T: @eknight
>   -- 
> 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 <javascript:>.
> For more options, visit https://groups.google.com/d/optout.
>
>
> -- 
> Learning Technologies Analyst
> MIIETL (McMaster Institute for Innovation and Excellence in Teaching and Learning)
> Mills Memorial Library L520 
> tel: (905) 525-9140 xt. 27497
>
>