Re: Credentials Use Cases document created

On 10/03/2014 06:39 PM, Nate Otto wrote:
> My favorite feature listed is probably composability, the ability to
>  present multiple credentials together to gain access to a system. I 
> see an opportunity to use multiple credentials to get over a hump 
> where one system knows an individual by one identifier, and another 
> system knows that same person by a different identifier. I think 
> being able to offer multiple credentials together for an 
> authentication/authorization request, with verified ownership of 
> each, could let people more naturally negotiate multiple facets of 
> their identity on the web. Though I think this is suggested by 
> composability, I wonder if it rises to the level of being a separate 
> use case.

+1, good point. You're right in that it is kinda covered by
composability. If we get that feature working, what you outline above
would be possible. However, since we're talking about use cases here, it
doesn't hurt to have two similar-ish ones to demonstrate what we'd like
to accomplish once we're done with version 1. As you know, as use cases
are concerned - when in doubt, add the use case. The very worst that can
happen is that the use case ends up being slightly redundant.

What about something like:

Enable credentials to be issued by systems in a way that allows each
system to align their internal identifiers with the other.

This means that all the two systems need to do to align with one another
is to just find a common identifier embedded in a credential.

Keep in mind that the current design we're thinking about has us
providing a portable identifier to a credentilee. So, for example, this:

{
  "@context": "https://w3id.org/opencreds/v1",
  "id": "did:df3b1ff8-4cc7-11e4-88a7-002522b76af4",
  "credentialService": "https://identityProvider.com/accounts/12345"
}

The "@id" is the thing that the Identity Credentials systems use to
assign credentials. So, System A could issue a credential like so:

{
  "@context": "https://w3id.org/opencreds/v1",
  "id": "http://ssa.us.gov/credentials/3732",
  "type": "PassportCredential",
  "claim": {
    "id": "did:df3b1ff8-4cc7-11e4-88a7-002522b76af4",
    "name": "Bob Bobman",
    "birthdate": "1985-12-14",
    "governmentId": "123-45-6789"
  }, ...
}

and system B could issue this credential:

{
  "@context": "https://w3id.org/opencreds/v1",
  "id": "http://dmv.ca.us.gov/cards/f7s9",
  "type": "DriversLicenseCredential",
  "claim": {
    "id": "did:df3b1ff8-4cc7-11e4-88a7-002522b76af4",
    "dmvNumber": "T83-8923238",
    "governmentId": "123-45-6789",
    ...
  }, ...
}

At this point, System A and System B both have the ability to align
against two separate identifiers. They can use the decentralized ID
"did:df3b1ff8-4cc7-11e4-88a7-002522b76af4", or they could use the
governmentId "123-45-6789". Some systems may want to use IDs that they
already have instead of the newer decentralized ID mechanism.

Keep in mind that the decentralized ID stuff is very experimental at
this point and assumes some sort of DHT-based lookup mechanism. Telehash
could be one of those mechanisms, but we're currently rethinking the use
of it and coming up with a more simple many-mirrors-of-a-single-database
approach (like git or Bitcoin), or a very simplified Web-based DHT.

> It looks like some very good work has been done leading to the 
> formation of this group, and I hope to help move it forward.

Thrilled that you're able to join the group, Nate. Looking forward to
collaborating :)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/

Received on Sunday, 5 October 2014 19:56:08 UTC