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

@Anh  You bring up some excellent points that we have been discussing
@OCG.  Although it may seem that some of what is being proposed may be
"overkill" and/or requires adoption by a larger ecosystem, that's because
it exists. IMHO identity credentials spans across industry, organizations,
business, government and education.  The goal is to build a specification
that is as inclusive as possible, allowing for privacy, portability,
extensibility and security.
On Feb 3, 2015 12:29 AM, "Anh Nguyen" <anh@anhnguyen.name> wrote:

> @Michael,
>
> 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.
>
> @Mo,
>
> 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.
>
> @Serge,
>
> 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
> 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.
> >
> > --
> > 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
> https://groups.google.com/d/topic/ba-standard/tE0vUv2BKNs/unsubscribe.
> > To unsubscribe from this group and all its topics, 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.
>