Re: Solutions to the NASCAR problem?

On 11/24/2015 02:40 PM, henry.story@bblfish.net wrote:
>
>> On 24 Nov 2015, at 15:58, Dave Longley <dlongley@digitalbazaar.com> wrote:
>>
>> On 11/23/2015 06:01 AM, henry.story@bblfish.net wrote:
>>>

<snip>

>>
>> This simplest approach for managing access to a resource merely based on what credentials someone has is to return a 401 response when a resource is requested along with a macaroon with caveats that must be "discharged" by providing the appropriate credentials.
>>
>> Then there are some authorization-delegation cases. One idea is that you could acquire a macaroon to get access to a resource or set of resources by authenticating yourself using credentials or an HTTP Signature. You can then use that macaroon to access the appropriate resources, or you can attenuate that macaroon and delegate access to someone else. You may attenuate it with caveats like an expiration date or a requirement that the recipient discharge the attenuated macaroon with a set of credentials.
>>
>> This approach doesn't add a lot of infrastructure and could integrate nicely with the Identity Credentials work.
>
> Could be, I'd have to look at it closer.
> The advantage of WebAccessControl which is employed by researchers under Professor
> Tim Berners Lee at the Distributed Information Group at the Massachusets
> Institute of Technology (MIT) is that it is
>
> 1) RESTful
> 2) ties in perfectly with Linked Data
> 3) is very extensible by tying into the work done by major instutions around the world on the semantic web stack,
> 4) ties in with other protocols from the W3C such as Linked Data Platform
>    http://www.w3.org/2012/ldp/wiki/Main_Page
> 5) being semantic is at its essence syntax neutral
> 6) we have at least 3 implementations of it already
> 7) should not be difficult to tie in with WebCredentials either
>
> see also http://www.w3.org/wiki/WebAccessControl

I'm not opposed to any of the above. The Identity Credentials work can 
be fairly agnostic with respect to authorization technologies. We will 
want to specify something when defining how one gets access to 
credentials via an HTTP API.

My interest has just been piqued by the macaroons research because it 
seems like a really simple, flexible, and powerful way to solve a lot of 
use cases.

>
>>
>> You could certainly set up some ACLs and some registration infrastructure and so forth so that access to resources could be determined by authenticating yourself as someone on those lists or as someone possessing a particular type of credential. However, that isn't necessarily scalable for a variety of other use cases and it doesn't support delegation.
>
> Why is that not scalable?

Involving registration infrastructure reduces scalability. The amount of 
information one has to store on a server with the macaroon solution can 
be greatly reduced vs. a traditional ACL-based system. A server can 
store a few parameters and an HMAC key vs. a comprehensive ACL. If third 
parties don't have to register with an ACL, that also makes it easier to 
delegate access more freely.

> Why does it not support delegation? We have a paper on WebID delegation and a wiki page on
> how to do it with WebID. This could also work for WebKey too.
>
>    http://www.w3.org/wiki/WebID/Authorization_Delegation
>
> And there may be other solutions.

I should have said that delegation is typically more limited in such 
systems. I only took a quick glance at the link above, but it seemed 
like you can only delegate access to someone who has a WebID. I'll have 
to double check that, but macaroons are significantly more flexible than 
that.

>>>
>>> Btw, issuers themselves can have WebIDs, and I developed the notion
>>> of institutional web of trust in 2011 at the eID conference
>>> in Switzerland
>>>
>>>     http://bblfish.net/blog/2012/04/30/
>>>
>>
>> Yes, in the Credentials CG, we have discussed the notion of issuers getting their own DIDs and credentials and so forth.
>
> I suppose credentials does not have to be tied to DID URLs either. They seem to me to be a great tool to have at one's disposal, but a URI referring to an agent is pretty much all one
> needs.

Yes, it's all URI based; any URI will do. DIDs are just one particular 
type of URI.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com

Received on Tuesday, 24 November 2015 21:19:46 UTC