W3C home > Mailing lists > Public > public-credentials@w3.org > December 2014

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

From: Brent Shambaugh <brent.shambaugh@gmail.com>
Date: Wed, 17 Dec 2014 15:43:52 -0600
Message-ID: <CACvcBVpqn=461-qtf2G66gR5bOyZ7G-q+ZAJxi43Fbo9o1vX3w@mail.gmail.com>
To: Nate Otto <nate@ottonomy.net>
Cc: ba-standard@googlegroups.com, Credentials Community Group <public-credentials@w3.org>, openbadges@googlegroups.com
Nate,

I found I got a lot out of the Internet Identity Workshop.
http://iiw.idcommons.net/Main_Page

-Brent Shambaugh

Website: bshambaugh.org

On Wed, Dec 17, 2014 at 2: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
>>
>>
Received on Wednesday, 17 December 2014 21:44:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:21 UTC