W3C home > Mailing lists > Public > public-credentials@w3.org > December 2015

Re: Verifiable Claims Telecon Minutes for 2015-12-01

From: Tony Arcieri <bascule@gmail.com>
Date: Tue, 1 Dec 2015 15:59:44 -0800
Message-ID: <CAHOTMV+=Nuq2nKXQQSh71uB76LLSJr3gfQMysaLh=Lbn1tviwQ@mail.gmail.com>
To: Dave Longley <dlongley@digitalbazaar.com>
Cc: "msporny@digitalbazaar.com" <msporny@digitalbazaar.com>, Web Payments IG <public-webpayments-ig@w3.org>, Credentials CG <public-credentials@w3.org>
On Tue, Dec 1, 2015 at 3:10 PM, Dave Longley <dlongley@digitalbazaar.com>
wrote:

> So, here we're talking about an identity credentials ecosystem where
> entities (eg: people) can collect verifiable claims about themselves,
> aggregate them into digital identities as they see fit, and then
> decide to share them as they see fit.
>
> This is different from an authorization credentials system, for example,
> where services want to restrict access to certain resources. Of course,
> a verifiable claims technology can be used to provide the identity
> and authentication piece for such a system, but it would not directly
> provide the authorization or delegation mechanism.
>

Identity-centric systems are exactly how we wind up with ambient authority
and confused deputies, because they cannot model authorization decisions
across more than two principals.

See: http://waterken.sourceforge.net/aclsdont/current.pdf


>> I would cite Macaroons as a system sufficiently flexible and
>> expressive enough to cover both cases:
>>
>>
>> http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41892.pdf
>>
>
> I think Macaroons would be a fantastic technology to explore using as
> the authorization piece of the puzzle; as a replacement for OAuth.
>
> Macaroons are an authorization and authorization-delegation tool. They
> do not provide identity or authentication. In fact, they are
> intentionally designed to operate at a different layer of abstraction.


Third party caveats in Macaroons are amenable to IdPs discharging
verification of identities.

I would look to Token Binding, Origin Bound Certificates, and Channel-Bound
Cookies as modern tooling for identity on the web:

http://www.browserauth.net/

These schemes are amenable to either self-signed origin bound certificates
autogenerated by the browser, or use with hardware tokens, smartphones, or
other e.g. FIDO U2F/UAF compliant devices for creating origin-bound
certificates that can be used for channel bound cookies.

Using Channel-Bound Cookies + Macaroons contextual caveats for binding a
token to an origin-bound certificate, you can use Macaroons as identity
credentials, which is particularly compelling for the IdP + third party
caveat case. Such a system allows an IdP to discharge an identity via a
holder-of-key proof *without* learning whom they're discharging an identity
for. This allows for privacy-preserving IdPs, which aren't possible using
any of the federated identity systems we employ today.

Or you can use Macaroons to bolster OAuth(2) as you describe if you do want
a strong connection between an IdP and the site they're authorizing use of
an identity for.

-- 
Tony Arcieri
Received on Wednesday, 2 December 2015 00:00:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:26 UTC