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

Responding to a few different posts on a couple of the forums this message
found its way to.

Thanks Melvin for the detailed reply,


I agree with you on the your first point for sure:

*On Wed, Dec 17, 2014 Melvin Carvalho wrote:*


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

Particularly big companies that think they can make a play to capture
users' identifiers in their own systems. I am glad to have the Credentials
Community Group thinking about how to collaboratively standardize identity
credentials. I'd like to keep Open Badges, well, open to the best
possibilities that emerge,and be able to issue badges to whatever facet of
identity that is known to an issuer, maybe even including the identifiers
that are used by Big Social Media.

>
>  Identification, authentication and authorization.
>

Yep, good to separate these functions when thinking about adding this kind
of feature to an ecosystem.

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

Yes. I would love to be able to use a public key in some form to denote the
recipient of a badge.

>
> 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.
>
>
>
I too lean toward using URIs when available for most identity types. For
example, if we added a Twitter username as a possible badge recipient, we
could use https://twitter.com/ottonomy instead of @ottonomy as the
identifier.


Sunny, it is also mentioned a little later in the standard that "email" is
"currently the only supported type" (see
https://github.com/openbadges/openbadges-specification/blob/master/Assertion/latest.md#primitives
)-- though there would potentially be no technical change to how other
identifiers were added to the spec, as long as they were a string. We may
want to consider other possibilities that may provide additional metadata
and come more into line with JSON-LD than simply saying you could add a
social profile URI in that field with a different type string.

*On Wed, Dec 17, 2014 at 2:52 PM, Sunny Lee wrote:*
>
> 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.
>

Yeah, and even software representing the earner could play this role in
some part. Now, the Backpack enforces a requirement that badges added to a
user's collection are issued to the email address registered to that
collection. Not all backpack-like software has this as a requirement.
(Badgr, for example, was built before I joined Concentric Sky to store
badges issued to any identifier.) Either approach poses significant user
experience challenges for earners and consumers.


*On Wednesday, December 17, 2014 3:01:28 PM UTC-8, Paul Cline wrote:*
>
> I am cautiously making my first comment in the forum. I have been reading
> (lurking) for a bit and thought I could add some ideas here.
>

Welcome to the Open Badges forum! Hope to hear much more from you over the
coming months.

>
> I agree with Nate that identity is a complex issue. Many people will have
> segmented identities based on their audience. Badges should accommodate
> these realities if possible and they should not inadvertently out someone's
> interest that are normal to one group but faux pas to another. A couple
> simple hypothetical examples, but let's assume with identity people's lives
> are deeply involved:
>
>    - A student athlete does not want her golf team to know about the
>    expertise she's building in motocross.
>    - An employee does not want his boss to know about his hobby.
>
> Good cases to consider.


> I suggest:
>
>    - earners should be able to have multiple identifiers affiliated with
>    their backpack.
>    - earners should be able to maintain multiple backpacks with separate
>    identifiers.
>
> The second, of course is already the case, but the first is something that
is very necessary (and also poses significant UX challenges -- the Mozilla
Backpack currently doesn't even have features that reveal to consumers the
single email address belonging to a collection owner, which is giving some
issuers headaches. Even serving their needs in the current case is a tricky
balancing act of Issuer, Earner and Consumer needs. I think it could be
done though).

>
>    - within a backpack it may be useful for earners to modify identifiers
>    on a badge
>       - They've lost access to that identifier (old school email) and
>       want to update contact info or identifier.
>
> I disagree with a strict sense of the word "modify", but this is a
long-standing downside to the current approach and something that must be
solved in the next year or so. I would like to see the same approach
followed in this case that I believe is appropriate for any badge, that
connecting an individual with an identifier is a trust matter between
earner and consumer (not affecting the issuer). I think helpful
widely-trusted third parties could be useful in this process, and I'm
excited by possibilities like the Identity Credentials technology in early
ideation at the W3C Credentials Community Group. Essentially, these are
verifiable statements by trusted parties (often trusted because of their
position in the network relative to a particular transaction)  about the
correlation between individuals and identifiers.

>
>    - earners should not be able to transfer credentials to false
>    identifiers; someone else's identifier.
>    - earners should be able to mask or hide badges that they do not want
>    a particular audience to see.
>
> On this last point, I look forward to experimentation in this community
and hopefully some good solutions.


> Thanks for all your hard work. I'm glad to join in the discussion.
>

Thanks Sunny, Paul, and all for kicking off an important conversation.


*Nate Otto, Developer*
concentricsky.com