Re: Solutions to the NASCAR problem?

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.

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.

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.

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.

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.

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

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


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

Received on Tuesday, 24 November 2015 15:59:34 UTC