Re: Solutions to the NASCAR problem?

Hi Henry

replace authentication with authorisation then what you say is correct.
All your 4 credentials are authz ones

regards

David

On 23/11/2015 11:01, henry.story@bblfish.net wrote:
> 
>> On 21 Nov 2015, at 16:41, Dave Longley <dlongley@digitalbazaar.com
>> <mailto:dlongley@digitalbazaar.com>> wrote:
>>
>> On 11/21/2015 11:30 AM, Steven Rowat wrote:
>>> On 11/21/15 7:31 AM, Dave Longley wrote:
>>>> On 11/21/2015 02:11 AM, Anders Rundgren wrote:
>>>>> I'm interested hearing what's available and what's cooking:
>>>>> http://indiewebcamp.com/NASCAR_problem
>>>>>
>>>>> Just the core (and links), no TL;DR BS please.
>>>>
>>>> There's a very simple demo here:
>>>>
>>>> https://authorization.io
>>>>
>>>
>>> Interesting. But I'm not sure it functioned as intended in my browser.
>>> Some steps were fully Graphic UI, whereas others, confusingly, printed
>>> full code on screen.
>>
>> Yes, the demo is very rough. I sent it primarily for Anders with very
>> little information, per his request.
>>
>>>
>>> I.e., in part of step two, at "Issuer Dashboard" what's between the
>>> '++++++' below appeared instead of buttons that I was expecting. This
>>> happened at two other places; but a GUI was fully functional before and
>>> after, in other steps. Is this the way it's supposed to function at
>>> present? [I'm using Firefox 43 on Mac OS 10.6.8]
>>
>> If you'd like to try something a bit more fleshed out (but still rough
>> in places and untested on Mac + Firefox), you can take a look at the
>> demo we presented on the Credentials CG call a little while back. I
>> recommend using Chrome.
>>
>> 1. Go to https://demo-idp.identus.org. Sign up for a fake/demo account
>> there.
>>
>> 2. Go to https://demo-issuer.identus.org. Login in and issue yourself
>> some credentials.
>>
>> 3. Go to https://demo-consumer.identus.org. Go through the various
>> demos, presenting credentials from step #2.
>>
>> This demo has only been tested on Chrome on Windows and Linux, and
>> Firefox on Linux. Using Ubuntu requires no special configuration, but I
>> know that if you're using Debian you have to click a box to allow 3rd
>> party sites to access localStorage via an iframe ... so maybe there is
>> something that is similarly required for Firefox.
>>
>> The demo shows three of the players in a potential future Identity
>> Credentials ecosystem: Identity Providers, Issuers, and Consumers. As a
>> credential holder, you are in the middle of those players.
>>
>> You use an IdP to store, provide, and manage your credentials.
>> Authentication with your IdP is just username+password at the moment,
>> but this could be anything in the future. The same authentication that
>> occurs at the issuer (credential-based authentication) can also be used
>> once you have a decentralized identity.
>>
>> Issuers issue credentials to you that you store at your IdP ... where
>> the issuer makes a browser API call to request storage (potential target
>> for standardization at W3C). Credentials are digitally-signed so that
>> consumers only need to trust issuers in the system, not your IdP. This
>> gives you agility to choose/change IdPs as you see fit -- or to use
>> whatever IdP you want (run your own, etc).
>>
>> Consumers consume credentials. They may ask for them using a browser API
>> call (again, target for standardization). The browser will figure out
>> who your IdP is so you can provide the credentials.
>>
>> 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. 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
> 
> 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.
> 
> 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.
> 
> 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/
> 
> 
>>
>> The concept is similar to getting a bitcoin wallet, but without the
>> unnecessary complexities of the blockchain or mining, etc. Once you have
>> this identifier, which is a URL with the new scheme "did", you can
>> associate credentials with it. You can fetch that URL and get back
>> public information about the identity, such as the IdP that is presently
>> associated with it. The IdP acts as an agent for storing/getting
>> credentials for that identifier.
>>
>> It should be noted, that credentials can be associated with any URL, for
>> example an HTTPS one. So the system is designed to work with these as
>> well -- and the technology could be standardized in steps over time. The
>> first "baby" step could involve registration of your IdP with the
>> browser rather than with a decentralized network. Of course, when
>> registering with the decentralized network, you get better portability
>> characteristics and so forth. The decentralized network or the
>> technology for it isn't built out yet, it is polyfilled, also by
>> authorization.io.
>>
>> Hopefully this explains some of the background and the concepts that are
>> being experimented with here.
>>
>> One more quick note about how the authentication works. When credentials
>> are selected at your IdP, they are wrapped up as an "Identity" (and
>> identity being a collection of identity credentials that assert various
>> claims about the identity). This identity and the target domain (the
>> consumer's) is digitally-signed at authorization.io (which would be the
>> browser in the future, it is just a polyfill). The digital signature
>> includes an identifier, a URL, for the public key used.
>>
>> If the URL has a "did" scheme, the related DID document is retrieved
>> from the decentralized network (polyfilled by authorization.io). Based
>> on some cryptography and a ledger), the consumer can trust the
>> authenticity of the DID document and can look for the public key therein
>> -- and then check the signature. More details about this decentralized
>> network are slowly being worked out here:
>>
>> http://opencreds.org/specs/source/webdht/
>>
>> If the URL has an "HTTPS" scheme, the CA system can be piggy-backed off
>> of, using the WebID protocol for authentication. Essentially, the public
>> key URL can be dereferenced, returning Linked Data that asserts the
>> owner of the key, which is a WebID, another HTTPS URL. That WebID URL
>> can be dereferenced to get more Linked Data that will assert that the
>> public key is truly owned by that WebID. The trust here, again,
>> leverages the existing CA system.
>>
>>
>> -- 
>> Dave Longley
>> CTO
>> Digital Bazaar, Inc.
>

Received on Monday, 23 November 2015 16:52:14 UTC