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

Chatting with Chris McAvoy, he pointed me to the identity object in the
standard:
https://github.com/openbadges/openbadges-specification/blob/master/Assertion/latest.md#identityobject

It looks like the open badges standard can support options other than
email. The issuer defines the identity object type. But as mentioned by
Nate it seems the 3rd bullet might be salient here:

   - 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.

Even if an issuer issues a badge using a different identity type other than
email, the consumer should ensure that the various identifiers are tied to
the badge recipient.


On Wed, Dec 17, 2014 at 12:17 PM, Nate Otto <nate@ottonomy.net> wrote:
>
> 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> 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.
>>> 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.
>> 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
>>
>>   --
> 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+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>