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

Cross-Posting

---------- Forwarded message ----------
From: Michael S. Evans <Michael.S.Evans@dartmouth.edu>
Date: Mon, Feb 2, 2015 at 4:11 PM
Subject: Re: [ba-standard] Adding an identity extension to the assertion
object
To: "ba-standard@googlegroups.com" <ba-standard@googlegroups.com>
Cc: "openbadges@googlegroups.com" <openbadges@googlegroups.com>


I am generally in agreement with Nate’s points here, particularly around
clarifying what problem we’re trying to solve, and for whom.

On the potential advantage of GUID over URI: if I understand what is being
proposed, in theory a GUID would be analogous to a Digital Object
Identifier (http://en.wikipedia.org/wiki/Digital_object_identifier) as it’s
used in digital publishing…basically as a pointer to the current valid URI.
In publishing, URIs change for a variety of reasons (access policy, archive
acquisition, technological upgrades, technical staff turnover, etc) in
unpredictable ways, and while in theory that would be resolved at the URI
level with something like a redirect, having a non-local solution for URI
lookup keeps the resources available to users in a consistent and
predictable way. But as with DNS, the lookup is handled by a separate
system (http://dx.doi.org). I would think that the GUID-URI link would not
be within the badge itself in this approach. My scholarly publication PDFs
do not contain a URL, but do typically contain a DOI. (And, incidentally,
the format of the DOI indicates the journal issuing the publication, via
assigned prefixes.)

Michael Evans
Neukom Fellow, Dartmouth College

> On Feb 2, 2015, at 3:35 PM, Nate Otto <nate@ottonomy.net> wrote:
>
> Interesting exploration of the ideas Anh started with, Serge.
>
> I'm glad Eric dropped in the links to the Credentials Community Group,
specifically to the draft Identity Credentials spec. That draft comes from
several years of work thinking about the problems that Anh and Serge are
reflecting on here. I'm not specifically endorsing this spec in its current
form as a solution to the problems you shared, but it is representative
about how good thinking on this identifier-identity connection is happening
all over the Internet. I would like to see Open Badges in conversation with
the best ideas developing around the world. I think this issue is bigger
than Open Badges and has to be solved in a wider conversation.
>
> That said, I think we need to more carefully define the "problem" we're
looking for a solution to.
>
> Some more specific thoughts:
>
> Anh wrote:
> > @Nate,
> It depend on the specific context.  We would assume there is 1 distinct
Issuer endpoint that point to 1 URI for the organization.  But that's not
being strictly observed.  There are multiple issuer endpoints for what I
know to be 1 issuing organization.  I see distinct URIs, which then has
some pieces of information in common, but others not.  Mix bag of sometimes
issuer description, name, URI, etc... not being the same.  Either using the
Issuer URI, or the URI field within that endpoint yield either a number of
duplications, or if I merge them then I lose relational integrity, and some
bits of information like different descriptions.
> I suspect it's a wider problem than even what I'm seeing.  Don't want to
point to specific examples since this is a public forum.  I'll send you an
email.
> I don't think organizations setting up multiple IssuerOrg files is
necessarily a problem to be fixed. It's not how I would set up my own
issuer program, but I can't say that nobody would have a good reason to do
it.
>
> We should be careful not to make over-broad assumptions about how users
should or must implement the OBI specification, because if we do, we might
shut down uses that stretch the spec a little beyond its initial intents. I
agree that it seems the first spec writers envisioned an issuer
organization with a 1:1 correspondence of organization to domain, so that
the consumer could tell if a hosted assertion was properly issued by that
issuer by asking if the assertion was hosted on the same domain as the
issuer. In practice, the badge ecosystem looks very different, and this
would be an unreliable method of answering the question of hosted assertion
validity across the board.
>
> As exceptions to that rule, we see issuers setting up shop on
multi-tenant platforms, like the Oregon Badge Alliance, Achievery, Credly,
Open Badge Factory, TrueCred, etc. We also see organizations defining
multiple "IssuerOrg" files all pointing to one
http://organization-canonical-domain.com . If your directory product wants
to make an attempt to connect different IssuerOrg definitions together
based on their shared 'url' property, that may be an appropriate decision
for your product. But I think it's unwise to assume that all consumers
should merge different objects that the issuer had created separately.
>
> As we build out a visible trust network with endorsement badges and we
adapt the specification or extensions to handle what some are calling the
"creator-issuer distinction", I think organizations will find it more
advantageous to unify their badging activity under one IssuerOrg, though
many may still find uses for hosting multiple issuer definition files, and
declaring authorization-like trust relationships between them. Tim Cook has
been doing some interesting thinking on what different relationship
declarations might be needed, depending on how we described the "problem"
and its "solution". One of the first uses of this exploration should be an
authorization-for-a-platform-to-create-badgeclasses-and-assertions on
behalf of an organization's badge issuing program.
>
> The "hard problem" at the root of whatever technical implementation we
provide is to connect the identifier for the entity (Issuer, Earner,
Endorser, etc) to the actual identity of a person or organization. The
Identity Credentials spec is an example of an idea for a technology that
makes this connection through a user's own trusted identity provider, which
relays credentials to the site that needs them. Any implementation of an
identifier to be used in badges, especially an arbitrary GUID, would need
to be attached to a protocol for a consumer to verify that the
person/entity they're talking to actually corresponds to the GUID presented.
>
> Michael is right to suggest that we should start from an assumption that
people have faceted identities (danah boyd's thesis has been on my to-read
list for a while), and that they should not be forced to reveal a
"canonical" identifier in order to earn usable open badges from a given
issuer. Serge's notion of a DNS-like service for badge identifiers is
interesting, but it would be a heavy lift to build. I would rather survey
existing technology more fully to see what already-created technologies
might serve our goals for decentralized identifier-identity connection.
>
> Anh 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.
>
> Anh, you're right that verification with consumers is the essential step
here, and we should assume that consumers have no special technical skill,
familiarity with badges, or specialized tools to perform the task.  Serge,
I'm looking forward to future discussions with you around the identifiers
that could be used in first implementations of Open Badges Passports.
>
> Serge wrote:
> >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.
> Take a look at that Identity Credentials spec for an idea of using
identity providers that are not "central". The login flow demonstrated
there still unfortunately requires synchronous participation by the user,
but in the use cases documents generated by the opencreds community, I
think there is the suggestion that users should be able to pre-authorize
certain other entities to retrieve specific credential/identifier
information.
>
> 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
> I don't quite see the advantage of GUIDs over unique URIs/IRIs for these
badge objects. Unless what you are meaning by GUID could be a URI (rather
than the common 32-digit version of guid, which is like
"21EC2020-3AEA-4069-A2DD-08002B30309D")
> 2) The badge assertion is stored in the passport/backpack of both the
issuer and earner
>
> This is an interesting and novel way to think of how badge objects are
created. It may have some power!
>
> 3) It is also stored in a public repository/directory. Let's call it for
now the Global Open Badge Repository (GOBR).
> I'm quite skeptical of the necessity or desirability of this centralized
step.
> Publication process
> --------------------------
> It is critical that only the badge earner is allowed to publish a badge.
> Is this really true? We have long held values about the badges being in
the earner's control, and the design of early badge infrastructure (the
backpack) somewhat reflects this value. However, the specification makes it
just as easy for an issuer to share as it does the earner. Would we want to
close off the possibility of issuer-publicized badges in the spec? I
suspect that a lot of the "killer apps" for badges may involve issuers
sharing directly with certain consumers. That said, I would be interested
in adding some additional protected possibilities for badge sharing (Like a
recipient->consumer encrypted badge transmission that is not
forward-shareable by the consumer without breaking the badge signature or
revealing the consumer's private key), (or requiring a credential of the
consumer in order to read the badge objects). It would require a large
change from the existing spec to disallow the issuer from sharing the badge
themselves, or to disallow consumers with whom the badge has been shared to
then share it forward.
>
>
> Thanks for thinking in depth on these issues. Keep it up. :)
>
> Nate Otto, Developer
> concentricsky.com
>
> --
> 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.

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