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

@nate +1

Respectfully cross posting to Credentials Group.


On Mon, 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
> <http://opencreds.org/specs/source/identity-credentials/>. 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
> <http://www.danah.org/papers/Thesis.FacetedIdentity.pdf> 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
> <http://concentricsky.com/blog/2015/jan/currency-your-credentials-3-trust-principles-building-open-badges-software>.
> 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.
>