W3C home > Mailing lists > Public > public-credentials@w3.org > February 2015

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

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Wed, 04 Feb 2015 12:30:12 -0500
Message-ID: <54D25724.9010502@digitalbazaar.com>
To: Nate Otto <nate@ottonomy.net>
CC: openbadges@googlegroups.com, ba-standard@googlegroups.com, W3C Credentials Community Group <public-credentials@w3.org>, Manu Sporny <msporny@digitalbazaar.com>
We should add discussing decentralized identifiers to the agenda for our
next Credentials CG telecon. There's a decent bit to talk about here and
we could also bring up some ideas from past discussions on the subject
(some from the Web Payments CG).

On 02/03/2015 08:59 PM, Nate Otto wrote:
> Mo, pleasure to read your post and glad to have your contribution to the
> thread. Thanks for diving in. Decentralized-yet-verifiable is a highly
> desirable feature for an identifier to be used in badge objects. I very
> much agree with the importance of being skeptical about any approach
> that requires a new huge centralized or federated system of identity
> verification.
> 
> I am deeply skeptical of approaches that create global registries of
> badges or complex centralized or federated systems to help map
> identifiers to other identifiers. I don't really see what problem is
> actually solved by creating either; at least I don't understand what is
> being described yet.
> 
> It would be my bias to:
> 
>   * Treat IssuerOrg objects that are separately hosted as separate
>     issuers, even if several are identical, hosted on the same domain or
>     point to the same 'url'.
>   * Maybe allow badge objects to declare a JSON-LD '@id' as a canonical
>     URL. (though I suspect a redirect would often be a more powerful
>     approach that would not require any changes to the spec verbiage?)
>   * When a badge object gives me a 301 Moved Permanently redirect, write
>     software that could understand that both URLs should be considered
>     to correspond to the redirected URL (I'd need to keep records of the
>     original location in the database in order to not need to fetch it
>     every time I came across a reference to it). Adds a little
>     complexity to the software, but is likely worthwhile.
>   * Explore extensions that would allow issuers to declare the
>     relationships between different hosted badge objects transparently.
>     Like endorsement, authorization-to-issue, "This other issuerorg file
>     is also me", etc. As someone writing badge-consumer software, if I
>     see any extension serving one of these purposes enter non-negligible
>     use, I'll probably build support for it into the system.
> 
> 
> If we're thinking of ambitious goals for the OBI, I think I share a goal
> with many others of having a reliable public key infrastructure attached
> to the badge ecosystem so that entities acting in their various roles as
> badge issuers, earners, and consumers can prove with a signature that
> they are the identity attached to the identifiers used in Badge Objects. 
> 
> I'd like to allow the same type of identifier (whether it be an email
> address, social profile url, public key) to be used as the identifier
> for any and all of the issuer, earner & consumer roles. Any identifier
> needs to be attached to a mechanism to verify whether the identifier
> corresponds to the person you're talking to.
> 
> *Nate Otto, Developer*
> concentricsky.com
> 
> (In other news, see my previous
> post: https://groups.google.com/d/msg/openbadges/9ehU2V4ceME/1DRdwEpmcs0J for
> the proposed draft badge endorsement extension that allows issuers to
> endorse badge objects with their URL as globally unique identifier)
> 
> 
> On Monday, February 2, 2015 at 11:09:11 AM UTC-8, Mo McRoberts wrote:
> 
>     Two small points, with apologies for diving in mid-thread and
>     top-posting…
> 
>     If URIs are used as the principle mechanism for identifying entities
>     (of any sort), then you can encompass UUIDs… and just about anything
>     else.
> 
>     Second, while there are plenty of centralised verifiable opaque (and
>     not-so-opaque) identifiers which a person might have, a hash of a
>     public key where they hold the private part (or it is held for them)
>     is on the very short list of decentralised-yet-verifiable opaque
>     identifiers which a person can have.
> 
>     (PGP key IDs and X.509 certificate issuer/subject identifiers are
>     minor variations on this theme)
> 
>     [[ In practice, under the hood, it works like this:
> 
>     Party A has the public and private parts of their key
> 
>     Party B wants to confirm that the identifier belongs to them
> 
>     Party B sends Party A a random blob and asks for a signature back
> 
>     Party A signs the blob with their private key (meaning anybody with
>     the public key can verify it), including a copy of the key
> 
>     Party B receives the signed blob and key, checks that the signature
>     matches the pubkey, and that the hash of the pubkey matches the
>     identifier it has; if it all lines up, Party A has proved their
>     identity to Party B
> 
>     In this context, this means that possession of a signing key deals
>     with both proof of identity (I’m the same agent as did this other
>     thing) and proof of issuance or earning (I did really issue or earn
>     this badge), which is from a purely technical perspective ideal for
>     badges. Everything else is fluff.
> 
>     ]]
> 
>     The downside, of course, is that sensible key management in modern
>     operating systems and browsers often leaves something to be desired,
>     although there’s been a renewed interest of late. Nonetheless,
>     keeping the *identifier* scheme open-ended means that it could be
>     implemented later without throwing lots of things away.
> 
>     I would *strongly* urge folks to aim for as decentralised an
>     architecture as is feasible and practical; a centralised or
>     federated model (where the latter is just the former with more
>     complexity and moving parts) will only cause pain later. Web
>     principles 101.
> 
>     I can’t see any obvious reason why there _should_ be a global
>     repository of badges, hierarchical or otherwise, although “services
>     which allow people to upload badges they’ve been issued, either for
>     backup purposes or to let others see them without sending them
>     around individually” are a Good Thing. A badge is a signed blob, and
>     blobs don’t need special magic to work, so you can e-mail it around,
>     or send somebody a URL to one, or upload it through a web form to
>     prove that you earned it.
> 
>     If done right, it shouldn’t matter if it’s possible for me to
>     publish somebody else’s badge, because I’d have nothing to gain from
>     it. Fraud shouldn’t be possible in the first place because the
>     earner’s identity, signed by the issuer as part of the badge, should
>     be something from which it’s possible to generate proof of. If it’s
>     not, the system is broken.
> 
>     M.
> 
>     On  2015-Feb-02, at 18:32, Serge Ravet <serge...@gmail.com
>     <javascript:>> wrote:
> 
>     > 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 "OpenBadges" group.
>     > To unsubscribe from this group and stop receiving emails from it,
>     send an email to openbadges+...@googlegroups.com <javascript:>.
>     > For more options, visit https://groups.google.com/d/optout
>     <https://groups.google.com/d/optout>.
> 
> 
>     -- 
>     Mo McRoberts - Chief Technical Architect - Archives & Digital Public
>     Space,
>     Zone 2.12, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA.
> 
>     Inside the BBC? My movements this week: http://neva.li/where-is-mo
> 
> 
> 
> 
> 
> 


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
Received on Wednesday, 4 February 2015 17:30:39 UTC

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