Re: Credentials Containers

On 01/20/2015 07:00 PM, ☮ elf Pavlik ☮ wrote:
> I just took another look at Identity Credentials 1.0 spec 
> http://opencreds.org/specs/source/identity-credentials/
> 
> I feel certain resistance thinking about all operations happening 
> directly on my identity document.

Why? :)

The reason we're doing this is because it seems to be the simplest way
of conceptualizing what we're attempting to achieve. We didn't want to
create a REST API ecosystem around identity credential documents - we
just wanted a simple document that you could read/write to.

> At the same time wondering if some conversations already happened
> about storing credentials in some kind of separate containers?
> Possibly something similar to Hydra Collection[1] or LDP
> Container[2]

We did have that conversation a long time ago. If we were to do that,
then clients would have to become much smarter... you'd need a LDP
library or a Hydra library and you'd need to have to know how to
navigate a URL space to get to the data you need.

One of the things we did with JSON-LD, which worked out pretty well in
the end, is to lower the barrier of entry to something Web developers
could easily wrap their heads around.

POST'ing to a single identity document is one way we thought of lowering
the barrier to entry.

The second you say: Here is a URL space, and you have to have a Linked
Data Platform or Hydra-aware client to navigate that URL space, you're
screwed. You lose developers.

> On fist thought it would allow storing different credentials on 
> different services. Also having different levels of security for each
> of them.
> 
> { "@context": "https://w3id.org/identity/v1", "id":
> "https://example.com/identities/bob", "type": ["Identity",
> "Person"], "credentialContainer" : [ { "id":
> "https://backpack.opentechschool.org/bob414", "type":
> "OpenBadgeBackpack" }, { "id":
> "https://supersecure.example.net/bob123", "type":
> "CredentialContainer" } ] }

We have been talking about the notion of "grouping" for display. As far
as "different levels of security", we don't think that grouping is the
proper way to do that - the use cases we have to support are far more
nuanced than simple groups are capable of addressing.

For example, my preferred shipping address credential should always be
accessible to my family, only accessible after grant to merchants that I
have bought items through, accessible for 6 months w/o request for
preferred merchants, etc. To make that happen shouldn't require that
credential to be stored in 3+ different places.

> I must admit right away not understanding how Access Control supposed
> to work with identity document.

Everything is under the control of the credential recipient. By default,
you must ask the credential recipient for access and they must
grant/deny the request interactively.

The other option is for the credential recipient to mark certain pieces
of information as public. There is an example of that implemented on:

https://dev.payswarm.com/

If you log into your account, click on settings, you'll see which parts
of your identity are listed publicly and which ones (such as email
address) are not.

The third option is to rely on the HTTP Signatures spec such that when a
digitally signed request for a particular credential comes in, an ACL is
checked and the information is returned if access should be granted
based on some prior authorization setup by the credential recipient.

> JSON-LD Frame, JSON Patch, JSON Pointer all currently don't belong to
> my daily toolbox. So question above comes bit more out of my gut
> feeling than solid analysis.

Gut reactions are good - we don't get to experience them that often, so
your feedback is very helpful. What are your thoughts now that you've
had a little more exposure to the thinking behind the spec?

-- 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 Tuesday, 27 January 2015 04:24:37 UTC