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

On 12/01/2015 06:59 PM, Tony Arcieri wrote:
> On Tue, Dec 1, 2015 at 3:10 PM, Dave Longley 
> <dlongley@digitalbazaar.com <mailto: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

The Identity Credentials/Verifiable Claims work is about making it
possible to make and verify claims about identities in a user-centric,
standard way. This work is primarily about making it easy for people to
go about collecting and aggregating (as they see fit) verifiable claims
that third parties make about them  -- and then being able to share
those claims with others, who can verify their authenticity. We may need
to better refine the problem statement in order to clarify this. We
welcome any specific language suggestions you may have.

I will say that it is certainly true that this technology can be
integrated with access control systems. However, how one goes about
modeling an access control system, whether that be via the ACL model or
the Capability model, is a separate concern.

But, in both models, the ability to authenticate identities may be
required. The intent of the Verifiable Claims work is to make it
possible for a system to authenticate an identity that is composed of
verifiable claims.

If you use the ACL model, authentication will be delayed until right
before an action is taken, potentially leading to a confused deputy
because resource designation occurs without authority. This is true
whether you authenticate using verifiable claims or some other mechanism.

If you use the Capability model, resource designation cannot occur
without authority; so the identity involved is tightly bound to a
particular capability for a particular resource. Authentication will
therefore occur during capability transfer, preventing any confusion
over which identity is attempting to interact with the designated resource.

Clearly the second model has advantages; but I believe this problem is
orthogonal to the Verifiable Claims work. It does fall squarely in the
realm of macaroons and, as I've said before, the two technologies could
play nicely with one another to implement these types of systems.

>> 
>> 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.

With the user-centric model, we don't necessarily want to limit people's
identities to particular origins. They may certainly do so at their own
discretion. However, there are cases where people want to present
identities that span across origins as they do with their non-digital
identities today.

> 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.

+1


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Tuesday, 8 December 2015 02:17:24 UTC