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

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

From: Eric Korb <eric.korb@accreditrust.com>
Date: Tue, 3 Feb 2015 07:03:01 -0500
Message-ID: <CAOyPhN+-WsQ=Tez4Rq8gmiQjydWv7+o5Ja=0+KG0U_TPtZUw_g@mail.gmail.com>
To: public-credentials@w3.org
Cross posting
---------- Forwarded message ----------
From: "Anh Nguyen" <anh@anhnguyen.name>
Date: Feb 3, 2015 12:29 AM
Subject: Re: [ba-standard] Adding an identity extension to the assertion
To: <ba-standard@googlegroups.com>


Your analogy with DOI is spot on, the model is the same.  I wasn’t actually
proposing that a unique ID be a replacement for the URI but rather as an
additional metadata to provide context.  In the case of the DOI, since
there are no privacy issues involved, there’s additional information being
provided that give context beyond just the URI, as well as a central
authority.  In json-ld there’s both an ID and a Context that add further
context and definition.   In the Badge Class and Issuer Class, there are no
such additional context possible currently.  URI were designed to find a
resource, not as a context giving metadata or a primary key id, they don’t
always work well for such usages.

The unique ID would be in the badge class url.  As Nate illustrated with
the multi-homed badges case.  What if an issuer organization did issued the
same badge(s) on multiple platforms with multiple badge class URL.  How do
we tell that it’s the same badge class or issuer?  Are we just going with
an assumption because they’re at different URI they must be different badge
classes or issuers?  Right now there’s no definitive way to tell the intent
of the issuer.

I suppose you could actually just stick in a  DOI number for the badge
class and issuer record,  but it wouldn’t work for the assertion well.
Some sort of unique id is purely more on trying to find something that can
possibly accomodate all those different scenarios and context, while still
be fairly light weight to implement at minimal.


The big downside to a key/pair type solution is I’m really ADHD, I’ve
actually lost a lot of private keys before.  I would actually be pretty
scared if that was the primary mean of maintaining my badges collection and
verification.  It bring up a whole host of other issues about key security
and backup.

There are varying levels for identity authenticity depending on the context
of who’s using the badge.  Key pair might be overkill for how badges are
being used in a lot of cases, particularly in primary Ed.

There’s also valid use cases for revocation and issued in error that make
offline badge blobs difficult to use as certification or value store.
Those are cases where I’m not sure if there’s a good solution to getting
away from using some sort of authoritative server.


Interesting model with the BUID and RUID.   But since most assertions
already have some sort of hash built in that make them very long, isn’t
that already a form of BUID, or already usable as a RUID if you just put
that into the appropriate spot in other records or usages?

Building network of trust web large enough that it’s usable for
verification purposes might be extremely difficult.  The same concept was
implemented for email digital signature as ID.  With widespread usage it
would be a very easy and effective mechanism to stopping SPAM, but even
with that as a personal incentive, barely 1.5M people globally use email
digital signatures.  Would you not need significantly more people to make
your relationship based endorsement work?

Anh Nguyen

> On Feb 2, 2015, at 1:17 PM, Michael S. Evans <
Michael.S.Evans@dartmouth.edu> wrote:
> I should mention that I realize that DOI is a URI in technical terms, but
that what I understand to be the GUID-URI distinction here is a similar
information model to the DOI-URL model in digital publishing.
> Michael Evans
> Neukom Fellow, Dartmouth Fellow
>> On Feb 2, 2015, at 4:11 PM, Michael S. Evans <
Michael.S.Evans@dartmouth.edu> wrote:
>> 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
>>> 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
>>> 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
>>> 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
>>> 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.
> --
> You received this message because you are subscribed to a topic in the
Google Groups "BA Standard Working Group" group.
> To unsubscribe from this topic, visit
> To unsubscribe from this group and all its topics, send an email to
> 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.
Received on Tuesday, 3 February 2015 12:03:29 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:38 UTC