W3C home > Mailing lists > Public > public-credentials@w3.org > November 2015

Re: Solutions to the NASCAR problem?

From: <henry.story@bblfish.net>
Date: Tue, 24 Nov 2015 19:40:25 +0000
Cc: Chadwick David <D.W.Chadwick@kent.ac.uk>, Steven Rowat <steven_rowat@sunshine.net>, W3C Credentials Community Group <public-credentials@w3.org>, public-webid <public-webid@w3.org>
Message-Id: <4CE2F9A1-0D4E-49C1-94AC-A51044AB78FC@bblfish.net>
To: Dave Longley <dlongley@digitalbazaar.com>

> 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:
>>> On 21 Nov 2015, at 16:41, Dave Longley <dlongley@digitalbazaar.com
>>> <mailto:dlongley@digitalbazaar.com>> wrote:
> <snip>
>>> The browser API is polyfilled using this library:
>>> https://github.com/digitalbazaar/credentials-polyfill
>>> It is meant to be an extension to the Credential Management API that
>>> Mike West has been working on:
>>> https://w3c.github.io/webappsec-credential-management/
>>> The Credentials CG has been in communication with him to ensure its
>>> design allows for these extensions.
>>> In additional to the browser API, another piece is required to polyfill
>>> what the browser must do. The browser needs to be able to discover
>>> user's IdPs; this is polyfilled by the authorization.io website. Part of
>>> the Credentials CG work is to make it possible for people to be in full
>>> control of their own identifiers. This is what the "Decentralized
>>> Identifier" (or DID) is about. This is basically an identifier that you
>>> can claim cryptographic ownership over (by generating public/private
>>> keypair and doing a claim).
>> I have a feeling that the missing piece here is that of the resource on
>> which the request
>> is being made by the user. I prefer to think of resources needing
>> authentication,
>> rather than whole sites, as different resources may require different
>> levels of
>> authentication.
> I believe you're talking about "authorization" here, not "authentication". Though the two are related, to be clear about the difference: authentication is about accurately identifying something. Authorization is about determining if that something should have access to something else/be permitted to take some action. It's a step further. Identity Credentials are about identity and authentication, not authorization. They can be used to authorize access or integrated with authorization technologies to provide the identification and authentication piece.

Ah yes of course, that was a typo of mine. Sorry about that.
My considered position is the one I just wrote to the list 

> The Credentials CG is exploring using something like Google's Macaroons (presently a research project) for simplifying authorization and authorization-delegation to resources. We're starting to see some nice ways that you can couple Identity Credentials with macaroons to get both authentication and authorization in a user-centric architecture.

To avoid searching the web in the future:

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

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


And there may be other solutions.

> By integrating with a technology like macaroons...
> If you want to give an application access to some set of resource of yours or to your credentials, you could get a macaroon by authenticating yourself to a "macaroon factory endpoint" for the service that hosts the resources. Then you add whatever caveats you feel are necessary to the macaroon and give it to the application. The application doesn't have to do any registration. You could also do this on a per-resource basis.
> If you want to give another person access to some resource of yours, you get a macaroon and add a caveat that the person using the macaroon must provide a credential that meets some criteria (identifies them as your friend, or as an employee, or as a medical professional, or as over the age of 21, etc.). To discharge the macaroon, they could provide that credential directly in the macaroon or specify its URL and their own macaroon with caveats for granting access to check it.
>> We get this on social networks all the time: some posts
>> require one to be friends with someone, other family, and others are public.
>> Many people don't have too many accounts, as it is a lot of work to
>> maintain one.
>> We should envisage cases that are more complex.
>> Our use case makes the hyperdata structure of the web site very visible,
>> so that it may well be that the same client needs access to
>>   (1) http://shop.example/drinks/beer/buy     <- proof of age
>>   (2) http://shop.example/profile/123/        <- proof of account creation
>>   (3) http://shop.example/bike/bmwk1200rs/buy <- proof of drivers licence
>>   (4) http://shop.example/xxx/kalashnikov  <- proof of participation in
>> well regulated militia
>> The client may have as policy only to ever authenticate when needed and with
>> the right credentails, as it is interested to make sure that the prices are
>> not being particularly tailored to the higer value for its profile.
>>  So we take it as a given that following RESTful architecture, it is
>> resources that require authentication. Hence we make it easy for any
>> resource to describe the type of agents and individuals that need access.
>> As shown on the Web Access Control page diagram, each resource (may)
>> point to
>> a description showing what types of agents have access.
>> http://www.w3.org/wiki/WebAccessControl
>> In that diagram the <2013/card> document there is open to read by
>> anyone, and the </2013/protected>  resource is only visible to members
>> of a specific group.
>> At present we have only considered WebID authentication as that was good
>> enough for our current needs, for a few small teams, where we need to
>> explore many other things including UI frameworks, LDP, etc...
>> But of course the description of the agents that get access to a
>> resource could
>> be much richer. The class of agents could be described as the class of
>> people
>> who can prove they are over 18, and that the site accepts certain actors as
>> verifiers of such proof. There may be a well established list for each
>> country of
>> such actors. In the case of driving licences it is clear that for most
>> countries in
>> the world the list of agencies able to proove the ability to drive is
>> quite restricted.
>> So each country could list its agencies, and list the agencies in
>> different countries
>> that fullfill the same role.
>> A client that comes across such a resource would then
>> 1. receive a 401 response
>> 2. follow the link to the Web ACL resource
>> 3. discover that it needs to show proof of a driving ability, and what
>> the relevant
>>    authorities for such claims are. ( the site may point to a few, but
>> the client
>>    may also compare that with its trust anchors, to find an overlap ).
>> For example
>>    in the US opening a bank account may be good enough to get a rifle,
>> but it
>>    Switzerland it requires being active in the milia .
>> 4. check the Credentials Wallet for any such claim
>>   a. if such a claim exists ask the user ( or follow a policy under the
>> users control for such situations )
>>   b. if such a claim does not exist, alert the user, and provide means
>> of him aquiring the credentials. This may require either just going to
>> the authority and getting the existing credentials, or doing a full
>> driving course, and passing the tests.
>>   c. one may want to discover on the side wether the sales requirements
>> are actually legally
>> sufficient for one's own authorities. I may be able to buy a gun in the
>> US, but not allowed to
>> with those credentials in france.
>> 5. if the user provided the credential use it for the next attempt to
>> accomplish the action
> As stated above, this approach could be implemented with macaroons by returning a macaroon in a 401 response. The macaroon would have caveats that must be discharged by providing the appropriate credentials. Once the macaroon has been appropriately modified, it can be submitted along with another request for the resource and access should be granted.

That's an intersting idea. Perhaps we could also return the ACL in a 401 response too, to
save one connection! I'd need to actually check if JS allows one to access the body of a 401 though.

>> So to summarise: to solve the NASCAR problem the client needs to
>> 1) have some way to access the list of credentials of the user,
>>   and their properties
>> 2) know which credentials are usable for the resource
>> 3) be able to discover how to create appropriate credentials
>> The Web Access Control "API" provides the minimum needed to answer 2) and
>> 3) . With this it then becomes possible for the client to retrieve the
>> right set of credentials.
> Giving the application a macaroon solves #1. Returning a macaroon with caveats when requesting the resource solves #2. I presume some informational data and endpoints for obtaining the appropriate credentials could be also included to solve #3.

Sounds interesting. So we have 2 possible solutions here. That's good for Credentials,
as it can be agnostic about which of these is adopted I suppose.

>> Because there are so many credential possibilities, and so many
>> attributes that may need to be verified, it is clear that this has
>> to be build up from the beginning in an extensible manner.
> Agreed.
>> 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


> -- 
> Dave Longley
> Digital Bazaar, Inc.
> http://digitalbazaar.com
Received on Tuesday, 24 November 2015 19:40:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:26 UTC