Re:

Mo,

> 2. I'd be wary of building a system whereby authentication
> tokens (i.e., client certificates) are issued in a
> centralised fashion — I'm increasingly becoming convinced
> that conflating the “identification” and “assurance”
> functions of an identity system is a fool’s errand, and that
> it would be wise to decouple them — in other words, I can
> use _any_ valid X.509 certificate to identify myself, but
> assurance information (such as institutions that I belong
> to, for example) while separate, is cryptographically
> associated (e.g., by way of a signature and
> countersignature). Separating the identification from the
> assurance data might also remove the need to extend TLS
> itself?

I think what you are describing is similar to attribute
certificates (RFC 5755).  There is a TLS extension for
sending attribute certificates along with a client
certificate (RFC 5878).  (I'm afraid we forgot to explain
how attribute certificates fit into our proposed
architecture, we'll have to add at the first revision.)

Attribute certificates are a good idea.  In some case that's
exactly what you need.  For example, if you ar applying for
a job (in the US), you may submit a certificate asserting
that your ssn is 123-45-6789.  If the prospective employer
is a defense contractor, you may add to that an attribute
certificate asserting that the owner of ssn 123-45-6789 is a
US citizen.

In other cases you want something else.  Suppose you keep
personal data in a personal data site, for the convenience
of maintaining it one place, and that site issues you a
certificate that you use to convey personal data to a
relying party.  Then you want to present two separate
certificates to the relying party: the one from the personal
data site, which may or may not uniquely identify you, plus
another one from the relying party itself that uniquely
identifies you to the relying party.  If the personal data
site goes out business and their certificate expire, you can
still access your account at the relying party with the
relying party's own certificate.

The TLS extension we are proposing let's you submit multiple
credentials.  It also lets you submit credentials that
provide more privacy than PKI certificates, such as Idemix
anonymous credentials or U-Prove tokens.

> 3. Broadly speaking, the reason that PKI-based identity
> systems haven't taken off to date, despite their ubiquity,
> has little to do with their inability to fulfil a technical
> purpose and more to do with the fact that the user
> experience of doing -anything- PKI-based outside of a
> corporate environment (and often inside one) is consistently
> confusing and unpleasant for ordinary users, and I'm
> including the problems of key management in amongst that.

Yes.  One thing that's particularly confusing and cumbersome
is certificate issuance.  We propose automating that process
by using TLS to issue certificates, not just present them.
I do realize that's a very big change, but I think it makes
sense.

> My gut feeling (and please don’t take this as a criticism of
> the paper — it's a more general comment) is that if a
> PKI-based identification system can be shown to be workable
> by real people in ordinary contexts (e.g., with extensions
> to browsers to aid key management and transport, identity
> selection, and so forth), then it's very easy to envisage a
> world in which strong crypto is used as the basis for
> identity on the Web, and that would be a very very good
> thing indeed. Without solving those problems, proposals
> based upon PKI and the like do very much seem like building
> the Eiffel Tower on sand: it's a nice design, but the
> foundations are seriously problematic.

Maybe now is the time to solve the problems :-)

Francisco