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

On 17 December 2014 at 21:17, 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.
>

Identity is not a technically difficult problem to solve on the web.  But
it is practically difficult to create a standard.  The difficulty typically
arises in getting people to agree.  This is quite understandable as
identity is quite a personal thing (we all have one) means something
different to every individual.

Firstly I'd like to separate 3 high level concepts before drilling into the
details.  Identification, authentication and authorization.  Some systems
separate these 3 concerns quite well in a modular way (e.g. apache authn vs
authz) and some closely couple the concepts.  More often authentication
(which is verified identity) and identity are tightly coupled.  This makes
creating a solution workable but creating an interoperable scalable
standard a challenge.

Regarding identification, it's the "hard problem" on the web, aka naming.
There are two styles in the arch of www.  Direct and indirect identifiers.
You may refer to a person directly (e.g. via name, url, etc. or indirectly,
the example given in awww is "10 Downing Street issued a statement
today...".  I'll cover direct identifiers, though it may be seen from the
get-go that there's a grey area here.  Note also that the identifier in the
standard may not be what is displayed on the UI, or what is used to login
-- e.g. facebook use graph.facebook.com as a primary key, display a user
name and login with an email address.

Typically direct identifiers come in the form of a URI, which is nice
because that's easy to code in JSON.  Two prevalent world views are to use
email (the mailto: URI scheme) and web based (the http: URI scheme).  Often
this is a polarizing force and one system with include one and not the
other.  A good standard tried to grow the network imho, so should b e open
to either (or more).  Note: More recently PKI and public keys are being
experimented with as identity, there are other schemes too.

Of particular convenience on the web is considered by many to use HTTP URIs
as a primary key for identity.  This has the advantages that many systems
already have http libraries, it's dereferencable to get more information
(the so-called "follow your nose" pattern), well tested, and has a variety
of authentication methods.

As pointed out identity is complex and can be spread over a large
footprint.  One method using HTTP to address this is to use the sameAs key
to indicate more of a keyring of identities.  Timbl himself also uses a
field preferredURI to indicate which is the "main".  But, perhaps this is a
whole discussion in itself.

In short, get an identity system up and running that works isnt too hard.
Creatign a standard is challenging to get people to agree, but I would
recommend using URIs in the JSON id, and have HTTP URIs in scope for doing
this.  The use that to create compelling UIs that hide this complexity from
the user, to create a similar user experience to facebook and other popular
social nets, but possibly more decentralilzed.



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