- From: Nate Otto <nate@ottonomy.net>
- Date: Tue, 3 Feb 2015 17:59:21 -0800 (PST)
- To: openbadges@googlegroups.com
- Cc: ba-standard@googlegroups.com, Credentials Community Group <public-credentials@w3.org>
- Message-Id: <227d35f3-aae1-4cf0-92c9-1b1d98a82182@googlegroups.com>
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 > > > > > > >
Received on Wednesday, 4 February 2015 01:59:52 UTC