- From: Francisco Corella <fcorella@pomcor.com>
- Date: Wed, 20 Jul 2011 12:21:20 -0700 (PDT)
- To: Mo McRoberts <mo.mcroberts@bbc.co.uk>
- Cc: "public-identity@w3.org" <public-identity@w3.org>, "Karen P. Lewison" <kplewison@pomcor.com>
- Message-ID: <1311189680.45485.YahooMailNeo@web125512.mail.ne1.yahoo.com>
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
Received on Wednesday, 20 July 2011 19:21:57 UTC