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

On 12/01/2015 04:08 PM, Tony Arcieri wrote:
> I was unable to attend this teleconference, but there was one
> objection I would like to raise:
>
> RESOLUTION: There is a significant difference between user-centric
> and service-centric architectures when it comes to verifiable
> claims.
>
> I strongly oppose this resolution, and believe this sort of thinking
>  is both deeply rooted in ambient authority systems and is the source
>  of confused deputy problems in multi-principal interactions where
> one of the principals is the user.
>
> A credential system which can securely solve 3+ principal
> interactions is by necessity dealing with the relationships between
> the user, service A, and service B (and potentially services C, D,
> and E)

First, to avoid confusion, the "credentials" we're discussing when we
talk about verifiable claims are "identity credentials", not
"authorization credentials". A verifiable claim is a non-repudiable
statement about an identity. You can use such a claim to authenticate an
identity; the decision as to whether or not an identity should be
authorized to take some action or access some service is a separate concern.

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.

To give an example of a verifiable claim use case:

A user visits a website ("consumer") to apply for a job. On their job
application, they are given the opportunity to offer proof that they
received an appropriate degree from a publicly accredited school and
that they are a US citizen.

In a service-centric system, the consumer may be registered with a
number of universities that the user can choose to be redirected to in
order to obtain some kind of authentication token.

The consumer may also be registered with a US government website -- and
then redirect the user to that site for them to obtain an authentication
token.

Each of these operations may also involve some other shared "identity
provider" (like a social web service) that the user must use to
authenticate against each of those websites in order to obtain their
authentication token.

In this system, the consumer may need to be tightly integrated with some
number of university systems. The university must implement some kind of
"identity provider" service for the user. The university is also fully
aware of the consumer of the user's credentials and is in the middle of
the relationship. The government site acts in the same way, and the
social web identity provider acts similarly in that it is aware of the
services the user is interacting with.

As a result of this architecture, the user has no choice but to fracture
their identities across multiple identity providers. They have no
ability to create cohesive digital identities in a way that they can
reason about. They also do not have strong control over their own
information. If they employ a shared identity provider service to help
them manage authenticating, they lose privacy, as they must share every
site they interact with. They have no ability to privately share their
claims with the consumer.

In a user-centric system, the user will visit the university website
independently and be given a verifiable claim that they store with some
agent, device, or service that helps them manage their claims. They will
do the same for the US government website. They can then provide those
claims to the consumer without those other websites involving themselves
in the transaction. The consumer can still verify the authenticity of
the claims made and decide if they trust the parties that made them.

The user is free to choose whatever agent, device, or service they want
in order to help them provide, manage, and aggregate their claims for
them; switching this agent out will have no effect on the trust between
the consumer and the issuers of the claims. If the user elects to use an
online service to aggregate their claims, that service does not need to
be made aware of with whom they share their claims; sharing can be
browser-mediated.

I think these two architectures have significant differences that impact
people's choices and ability to create, control, and manage their own
digital identities.

>
> I would argue that if a credential system is inflexible to the point
>  it is unable to model both the authority of human principals
> (vicariously via their user agents) and service principals, that is
> in fact a failure of the design/expressiveness of the credential
> system, and in no way a desirable property.

Could you describe a scenario that you believe cannot be modelled by the
architecture presented?

>
> 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.
They provide a place for an identity + authentication mechanism to
insert itself in order to "discharge caveats". For example, verifiable
claims technology could be employed to discharge Macaroon caveats,
authenticating the user of a Macaroon. Alternatively, a service-centric
identity credentials mechanism could be used, but it would bring with it
the drawbacks stated above. From my point of view, user-centric
verifiable claims technologies and Macaroons would complement each other
quite nicely; they do not compete.

With verifiable claims technology people can control their identities
and how they present themselves to websites. With Macaroons, services
can control and delegate authorization to access resources. By combining
both technologies, services can limit authorization to resources based
on whether or not people have provided the appropriate verifiable
claims. People can delegate access to resources by attenuating Macaroons
with caveats that require further verifiable claims.

These two technologies are more decentralized than their
predecessors and they seem to complement one another quite well.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com

Received on Tuesday, 1 December 2015 23:11:08 UTC