Multiple Id's per badge: Palimpsest Method

[cmcavoy]

Multiple Identities Per Badge, Palimpsest Proposal

The Problem

When you're issued a badge, a single identity, usually an email, is the only identity you're allowed to associate with a badge.

Proposed Solution

Extend the assertion specification to allow multiple identities per badge.

The problems created by the solution

Presumably, an issuing organization will only know one identity for the earner of the badge. They'll issue to that identity, maybe signing the badge. The signature will be based on a badge issued to a specific identity.

If a second service adds another identity to the badge (say, a backpack), then the badge signature becomes invalid.

Proposed solution to the problem created by the solution

When a secondary organization adds another identity to the assertion, they add a second signature, and clearly mark the ways they altered the original assertion. Multiple additions could be added this way, with a moderately complicated process of peeling each layer away and re-validating the badge.

Palimpsest?

[ottonomy]

I like that you're thinking along these lines. I suspect there are useful ways a baked badge could be modified after issuance that would be understandable to a machine examining the case.

I just had a long conversation with my partner about badge extensions, and how we could possibly explain them to people so that they understand what we're talking about. And how we could possibly create them so that implementing them is manageable across different players in the ecosystem.

Adding a solution that has its own problem and solution is a wild place to start from.

Am I summarizing your idea right? Here's separating the new signature components with some extra space (pretend the json is base64 encoded)

{ "alg": "sha256" }

.

{
// json badge modifications:
"@amender":{
  "site": "https://amender.org/issuer.json",
  "verify": {amender's public key}
},
"recipient": [{original},{new}],
"recursivePalimpsest": "{ 'alg': 'sha256' }.{ json badge assertion }.signedhash"
}

.

signedhash2

I'm not 100% sure about how the actual assertion signature goes into the badge. Does the "openbadges" iTXt chunk actually consist entirely of a JWT rather than a JSON blob as above? alg.assertion-json-base64-encoded.signature?) I don't think I understood how it was structured when I wrote my previous assertion-extension proposal.

I'm trying to think of this from the perspective of somebody who writes an application that is trying to understand a badge. It would be a pretty complicated change from present implementation to say that the analysis needs to dig into the innermost layer of the palimpsest, validate, then amend with outer layers, revalidating & examining who did amendment at each step until outermost layer is reached. Cool, but complicated.

How would you organize the results of such an investigation into a badge to present to a human for judgement? How would you teach a computer to understand each decision?

[cmcavoy]

I'm trying to think of this from the perspective of somebody who writes an application that is trying to understand a badge. It would be a pretty complicated change from present implementation to say that the analysis needs to dig into the innermost layer of the palimpsest, validate, then amend with outer layers, revalidating & examining who did amendment at each step until outermost layer is reached. Cool, but complicated.

Yeah, I think it would be pretty complicated to write an app that does this.

How would you organize the results of such an investigation into a badge to present to a human for judgement? How would you teach a computer to understand each decision?

I was thinking a timeline. "On Jan 1 2014 this badge was issued to chris@someuniversity.com by someuniversity.com, on June 1 2014, the email identity chris@mynewjob.com was added and verified by Independent Badge Verification Service Inc (IBVS). For information about IBVS, including community endorsements of their services, go to ibvs.badges (in this future, .badges is a top level domain.)"

The idea would require trusted third parties that would first validate that the original identity associated with the badge belonged to the earner, as well as the additional identity. If the badge is issued to an identity that the earner can't validate beyond some certain point (like a university email address they lose access to, the classic use-case that comes up allll theeeee tiiiiiiime) then the third party that "re-signs" the badge needs to be very trustworthy, and the earner needs to get the badge re-signed before they lose access to the original identity.

All in all, it's a tricky solution to a tricky problem, and requires some large ecosystem players to emerge and be trusted.

[jeroenlicht]

Hi all, I just signed up for GitHub to join this conversation since I figured this would be a problem when using openbadges for our project where we want to provide accreditation. As a workaround, I am thinking of providing the possibility for users to re-create their earned badges from us after changing their email address in our system.

Would it be a problem to distribute a new version of a badge with the same uid and issuedOn date? Or would it be better practice to give the re-issued badge a new uid and/or new issuedOn date?

For instance, when the badge (image) with the old email hash had already been distributed and added to badge displayers such as backpack, does adding the new one with the same uid maybe cause problems with badge-displaying systems?

[ottonomy]

As another approach, I'm fond of ways we might issue a badge that makes the claim "zzz@example.com" is another identifier for the person who is formerly known as "prince@aol.com". And then ways these tokens could be presented with a collection of other badges to let a consumer know that a trustworthy third party considers the multiple identifiers equivalent.

The credentials work moving forward at the w3c credentials community group has some interesting relevant approaches here. http://opencreds.org -- The idea being an identity document that can contain multiple credentials and information about multiple identifiers and additional metadata (name, address, etc) corresponding to that identity, paired with access control making sure to only release that to authorized parties.

[timothyfcook]

Moving to archive. Multiple identities now supported: https://github.com/openbadges/openbadges-specification/pull/99