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

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