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

@Nate, thanks for cross-posting to both groups.  Accreditrust believes that
identity is a critical element for digital-credentials (credentials).
Accreditrust believes that we must be able to prove without a shadow of
doubt who issued the credential; who it was issue to (recipient); and a
consumer system should be able to verify that proof.  Otherwise, we feel
the promise of using credentials as professional currency will be lost by
those who would exploit any vulnerabilities in the credential's
authenticity.  (Ask Sony about vulnerability...)

Accreditrust also believes the Issuer should always verify the identity of
a recipient prior to asserting a credential.  Furthermore, Accreditrust
feels that the identity of the Issuer should be able to be verified in a
way that cannot be spoofed.

The Credentials Community Group is addressing these uses cases as part of
its Design Criteria.  We presented these concepts at the the W3C TPAC event
this past fall.  See presentation slide
http://opencreds.org/presentations/2014/tpac-wpig-ccg/#slide10  We also
presented these views at the Internet Identity Workshop as @Brent pointed
to.

Like you said (@Nate and other will follow from the CCG), this is not an
easy problem to solve.  That's why as a community we should strive to
figure this out together.

Much of the difficulty is rooted in supporting portability of credentials.
Using a visualization, here is what Accreditrust sees as the challenges of
portability:  Suppose two people place their wallet on a table.  How do the
respective owners prove who owns which wallet? How do you know if someone
didn't switch the credentials between the wallets when someone wasn't
looking?  Suppose you receive a new wallet as a holiday gift.  How to move
your credentials to the new wallet without compromising the verification
policy that was used to prove it belonged to the original wallet?  How do
you verify ownership of a copied credential, such as a insurance card, that
you placed in your wallet?

We are starting to see insurance companies (i.e., Geico) and state
governments (i.e. Iowa, New Jersey) who are starting to or contemplating
the presentation of a credential on a smart phone.  This sounds like great
idea, but there are obvious security questions that come to mind with
respect to proof of ownership.

In the above examples, think of the wallet as a backpack, and credentials
as badges.  Being able to select which backpack to curate your badges
should be up to you (the recipient).  And, you should be able to move your
credentials anywhere you want without losing the ability to verify them.

Lastly, Accreditrust feels that your identity should be portable and not
locked to a single identity provider.  Using email or a social network user
account for your identity is easy and convenient. But, when was the last
time any of these service providers did a background check to prove your
identity? You should be able to establish your identity with a service that
provides a means to prove your identity, and should be able to move from
one provider to another at will.
Eric

On Thu, Dec 18, 2014 at 11:52 AM, Sunny Lee <threeqube27@gmail.com> wrote:
>
> Nate,
>
>>
>> Sunny, it is also mentioned a little later in the standard that "email"
>> is "currently the only supported type" (see
>> https://github.com/openbadges/openbadges-specification/blob/master/Assertion/latest.md#primitives
>> )-- though there would potentially be no technical change to how other
>> identifiers were added to the spec, as long as they were a string. We may
>> want to consider other possibilities that may provide additional metadata
>> and come more into line with JSON-LD than simply saying you could add a
>> social profile URI in that field with a different type string.
>>
>
> I see what you mean. I believe this needs to be updated. I think the
> standard supports multiple types while the Backpack does not. I will update
> the documents.
>
>
>
> --
> 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.
>