Re: Solutions to the NASCAR problem?

Hi Dave

your system has some similarities to one we developed 4 years ago under
the EC TAS3 project. I gave a demo and presentation at the W3C meeting
in Mountain View in 2011. The slides are here

http://www.w3.org/2011/identity-ws/slides/Chadwick.pdf

The technical details are in a paper I presented at the ARES conference
in 2013 (if anyone is interested). The system was based on SAML
assertions which were aggregated from multiple authorities. The protocol
however is not that important as subsequently I designed an alternative
based on UMA. It is the concepts and models that are more important.

However, things have moved on significantly since then. My latest design
is based on FIDO, and it does not need IdPs anymore. IdPs morph into
attribute authorities (AAs) as now they only assert user attributes
(credentials) for the user. The user can authenticate himself to the SP
and the AAs with his FIDO keys. Un/pws are no longer needed (unless you
use the U2F model instead of UAF).

Credentials are digitally signed by their issuers (AAs) so the trust
model is the same as yours.

No discovery of IdPs or AAs is needed, as AAs are recorded in the FIDO
metadata.

DIDs are now the users keys with SOP.

The user stores his credentials on his FIDO device and so has full
control of them.

I suspect this system is simpler than the one you describe below

regards

David


On 21/11/2015 16:41, Dave Longley 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).
> 
> 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.
> 
>

Received on Saturday, 21 November 2015 20:12:48 UTC