Re: Solutions to the NASCAR problem?

Hi Dave

On 22/11/2015 01:28, Dave Longley wrote:
> On 11/21/2015 03:12 PM, David Chadwick wrote:
>> 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.
> 
> Thank you for the slides. The system you describe is very similar to the
> Credentials CG work. One minor point of confusion is around what IdPs
> represent in the Credentials CG work. They are not like IdPs in SAML,
> where they essentially double as what we refer to as issuers. IdPs do
> not make assertions nor do they necessarily do any direct communication
> with consumers (SPs) or issuers (AA).
> 
> Issuers make the assertions and IdPs simply aggregate them. They are
> more like "Identity Agents". Another key difference from the SAML or
> OpenID Connect architecture is that this new architecture does not
> require users that share credentials to reveal the identity of the
> consumer to their IdP (agent) or to issuers.

Thanks for the clarification. And I agree that the non-reveal property
is an important feature.

> 
> As you stated in another mail, we should be more clear about definitions
> in the Verifiable Claims proposal as well.
> 
> You can think of Credential CG IdPs as playing the same role that a FIDO
> device plays in your system, but they are expected to be implemented as
> services. I see no reason why they can't also be implemented as a device
> (or a service on a device), however, there are problems with that
> approach, the most glaring one being that people lose their devices.
> 
>>
>> 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
> 
> The two systems sound very similar in architecture, probably more than
> you could have known prior to the IdP clarification.
> 
> Again, the main difference is that we recommend that an IdP be
> implemented as a Web service, though, it could be on a device.
> Implemented as a Web service, however, to which the user can
> authenticate with a FIDO device, is a better option, in my view. It
> helps users cope with the fact that many of them, will at some point or
> another, lose their device. Having to revisit all of the issuers (AAs)
> you received credentials from because you lost your device is painful
> and may even be extremely difficult in some cases.

But if I can only authenticate to my IdP from my FIDO device, and I lose
my FIDO device, then I am in a similar situation as in my model.
Admittedly I only need to prove who I am to one entity (the IDP) rather
than multiple ones (the issuers), but in the real world this is handled
today by companies, TTPs, who will contact all your credit card and
other issuers for you, and get you a new set of credentials. So this TTP
could be an additional optional web service in my model which would then
make the two models equal in terms of loss of FIDO device.

regards

David


> 
>>
>> 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 Sunday, 22 November 2015 13:42:05 UTC