Re: Credentials Containers

On 01/27/2015 05:24 AM, Manu Sporny wrote:
> 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? :)
I think because I don't understand details of how *access control* will
work on such a single document.
I cc Markus Sabadello who has tons of experience in that field from his
work on http://xdi2.org and https://respectnetwork.com and who also
joined this CG.

> 
> 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.
IMO most developers thinking about read/write may tend to assume
capacity to read the full resource/document as well as update(replace)
such full resource/document

> 
>> 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.
Could you please share a link to records of this conversation?

> 
> 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.
I didn't suggest requiring clients to fully implement LDP or Hydra. I
only used is as a reference to existing work, which I stay aware of, for
creating Linked Data Collections/Containers and following REST
principles to different extent.

Following your reasoning, IMO building around JSON-LD Frame, JSON Patch
and JSON Pointer possibly could have similar effects.

> 
>> 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.
I recall Open Badges having some notion of *groups*
https://github.com/mozilla/openbadges-backpack/wiki/Using-the-Displayer-API#querying-for-badge-groups

> 
> 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.
1. Who issues your shipping address credential? (for me it seems like
piece of data about myself which I would simply add myself to my online
profile)
2. Could you write in more detail how you plan to implement this
particular ACL? Including example HTTP req/res for defining all those
constraints and how to internally verify them and produce responses
which include expected data?


> 
>> 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.
To my understanding currently it allows me to see all the data if i
authenticate as myself. Then just subset of data for all not
authenticated requests. How do you store those rules and based on them
generate appropriate response for not authenticated requests?

> 
> 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.
How do you define this ACL and how do you check it for a given request?
I really think some detailed examples would come very helpful for me and
other people to understand it.

> 
>> 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?

Thanks Manu for all those clarifications! I really appreciate your
thinking behind it :) Now I just need to understand better technical
details of proposed implementation pattern.

Cheers!