Re: Solutions to the NASCAR problem?

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.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Saturday, 21 November 2015 16:41:45 UTC