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

On 01/12/2015 23:10, Dave Longley wrote:
> 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.

I think you do a disservice to the credential system if you try to
separate the two functionalities. In the ABAC model, an identity
credential is an authorisation credential, since privileges are assigned
to identity attributes. So the credential can be both (and I would argue
is always implicitly both). It is a decision of the recipient how it
chooses to use the presented credential, whether to use it 'just' for
identification, or for identification and authorisation. I would argue
in fact, that a recipient never uses it just for identification. Even in
your use case below, the identity credential is actually an
authorisation credential for the job application. If the user cannot
prove they have a degree or other identity attribute that the recipient
requires, they will not accept the application and say the applicant is
not qualified for the job.

You may think that a law enforcement officer who asks to see your
identity credential in the street only wants it for identification, but
not so. They want it to prove that you are authorised to be here, and
are not an illegal immigrant. So I would be interested to see a use case
in which an identity credential is only ever used for identification and
never for authorisation.

regards

David


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

Received on Thursday, 3 December 2015 13:20:19 UTC