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

On Mon, Dec 7, 2015 at 6:16 PM, Dave Longley <dlongley@digitalbazaar.com>
wrote:

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


You might want to check out what the IETF Token Binding working group is
doing:

https://datatracker.ietf.org/wg/tokbind/charter/
http://www.browserauth.net/

This is a joint effort by Google and Microsoft, the results of which will
likely end up in Chrome and Edge.

They are specifically working on solutions for identity which follow the
same-origin policy, such as origin-bound certificates (which can
potentially be generated by e.g. a U2F/UAF token). By following the
same-origin policy, these sorts of systems eschew problems around ambient
authority and confused deputies, and also eliminate confusing user
decisions by always doing the right thing: creating unique public key
identities per site, and only allowing those identities to be used on the
site where they are provisioned.

Once you have this building block, however, you can build federated
identity/access systems using the following approach:

https://fidoalliance.org/wp-content/uploads/2014/12/DraftD-FIDO-Refarch-00.pdf

[image: Inline image 1]



> We may need to better refine the problem statement in order to clarify
> this. We
> welcome any specific language suggestions you may have.
>

"Claims" have a very specific meaning in federated identity and access
systems, specifically those that come out of the "Zebra Copy" / SAML
heritage. I would generally class them as AuthZ instead of AuthN, however
it sounds like you're using the word "claims" to mean Claims-based Identity
exclusively. I say it's AuthZ because fundamentally the IdP is authorizing
a particular principal to use a given identity.

I understand you're trying to steer away from the word "identity", possibly
due to the long history of failed W3C projects around identity, but it
sounds like you are taking claims, which are a generic idea, and use them
exclusively for identity systems.

All that said, I am not a fan of SAML and JWT: they try to solve what is
fundamentally a multiparty AuthZ problem without cryptographically binding
together credentials and claims. This leads to a class of attacks where a
claim meant for party A can be used by party B. This was "solved" with
optional AudienceRestrictions in SAML 2.0 and the "aud" attribute in JWT,
but the latter remains optional and is not enforced. I've spent a long time
studying attacks on systems like these, and also the EMV protocol which has
similar issues, and my feeling is the root cause is a failure to
cryptographically bind together all involved principals (e.g. using
"holder-of-key proof" systems)


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

It sounds like what you're describing is fundamentally a Claims-Based
Identity system, and it would be much less confusing if you just called it
an identity system, or used claims to their full potential (as an AuthZ
tool).

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.


Macaroons can be used to model IdPs via third-party caveats / discharge
macaroons, but using them solely for the purpose of IdPs is using a
fraction of their potential, which I guess gets back to my gripe about
taking claims and using them exclusively for Claims-based Identity. They
are one of the few technologies, however, that bind together credentials
from multiple principals cryptographically, which not only dramatically
reduces attack surface (see previous complaints about SAML/JWT audiences),
but also enable privacy-preserving IdPs where an IdP can authorize a
principal to use a particular identity without learning the third party
they are authorizing an identity for.

All that said: multiprincipal (3+) authorization decisions are an extremely
difficult problem. Failure to solve the problem correctly gave us such
attacks as CSRF and SAML confused deputy attacks where users are either
authorized for the wrong audience or an audience misinterprets claims
intended for a different audience.

--
Tony Arcieri