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

Cross-posting


---------- Forwarded message ----------
From: Serge Ravet <serge.ravet@gmail.com>
Date: Mon, Feb 2, 2015 at 1:32 PM
Subject: Re: [ba-standard] Adding an identity extension to the assertion
object
To: ba-standard@googlegroups.com
Cc: openbadges@googlegroups.com


I fully agree with Anh. A GUID (or UUID, Universally Unique IDentifier) is
a direction worth exploring — it's anonymous, it can be associated with any
existing identifier, made public or kept private and we can generate more
GUID than there are particles in the universe!

The question are:
- how can we be sure that a GUID is and will remain connected to a unique
person (anyone could claim owning the same GUID) without having to go
through a central authority?
- how can we be sure that the number of data connected to the same GUID
will not permit to identify that person?

If we agree (for a moment at least) that a badge is a relationship between
an issuer and an earner, could we think one step further and imagine that
each badge generates a RUID (Relationship Unique IDentifier)? Then we might
not need a personal GUID anymore, or more precisely, we could choose any
RUID as a pointer to any personal identifier. After all, our first very
first identity (identifier, to be correct) is "son/daughter of ..." Now
let's imagine for a moment that we live in an environment where there are
no personal identifiers but only relational identifiers (daughter of,
trusted by xwz to do this and that, etc.), how could that work? What would
be the benefits? — for example, in the Icelandic culture, there are no
family names, everyone has one or two names and is referred to as the
son/daughter of his/her father.

The very first benefit of such an approach is that there is no need for any
central authority, what is usually called 'identify provider' (which should
be called 'identifier provider'). The other benefit is that we are not
limited to a single identifier but we could combine many to prove who we
really are. For example, proving that you are over 18 in a space with no
official ID card could be done by having "over 18 of age" endorsed by other
trusted members of the community — identity through others This is
something easy to do in the digital world once we have established networks
of trust.

So my suggestion is the following:
1) A badge assertion is composed of: BUID (Badge GUID) + issuer GUID +
earner GUID + criteria URI + evidence URI + extensions (place, language,
etc.) + hash code/fingerprint
2) The badge assertion is stored in the passport/backpack of both the
issuer and earner
3) It is also stored in a public repository/directory. Let's call it for
now the Global Open Badge Repository (GOBR).
4) A badge is generated with all the metadata, except  the  issuer and
earner GUIDs (and, if the earners wishes so, without the evidence URI if
the evidence contains nominative information and wishes to remain fully
anonymous).

The BUID establishes a relationship between the issuer, earner and the
associated metadata. The BUID 'is' the RUID. No need to disclose any issuer
or earner GUID as the Badge UID subsumes both.

The function of the GOBR is:
1) to keep a record of all the badges issued. The only public information
is the list of GUIDs and their associated criteria. It could store badge
classes as well as instances (assertions).
2) to maintain consistent links between GUIDs and passports/backpacks, so
passports and backpacks can be accessed without having to reveal their
actual addresses. It is important also that the link between GUIDs and
backpacks can't be changed,  as it could be a means to transfer one's own
badges to someone else.

In a sense, a GOBR  is to Open Badges what a DNS is to the Web: a random
number / UUID (resp. URL) is translated into the address of a
passport/backpack + Badge (resp.IP address).

We now have a fully anonymous, yet trustworthy, space.

The issuer and earner GUIDs could be the BUID of any badges they have
earned, including self-issued badges.

Publication process
--------------------------
It is critical that only the badge earner is allowed to publish a badge. It
is also important also to keep the process as simple as possible without
requiring special developments for integration. It should be as easy as
adding a picture. To provide a level of verification, it is possible to a)
use an image stored in a trusted space and b) use the link to provide
additional services/data.

1) the earner adds a badge to a site — at this stage the badge is just a
picture
2) the earner provides its passport/backpack with the URL where the picture
of the badge is located and its BUID
3) the backpack calls a GOBR service that verifies that the badge is
present and returns a URL to add to the picture.

The URL points indirectly to the badge in the backpack of the earner. To
avoid fraud and preserve anonymity, the address is something like
http://www.opengadges.org/<encoded address of the earner backpack/badge>.
The encoded address tells the GOBR to use the link to the backpack to
display the information.

Verification process
---------------------------
The address where badges is published being registered in the GOBR, web
crawlers could discover stolen badges.

Of course, this is just a very coarse demonstration, but I believe that
there is something worth exploring: moving from identifying individuals to
identifying relationships...

What do you think???



On 31 Jan 2015, at 21:50, Anh Nguyen wrote:

> On the user side, GUID can be both a public identifier, as well as a way
to anonymize.  Its primary feature is persistency in a way that is platform
agnostic.  But you're not limited to having a single GUID.  You could
potentially have 10 that each are associated in a specific context with
different communities.  The only thing in common is globally, there exist
the idea that there is 1 person associated with each of those GUID,  the
issuer of the badge know your authenticating information.  It's up to the
owner of the ID to associate additional identifiers like Twitter, email,
name, and to decide if/how to publicize that association for verification
with consumers.
>

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