[KI-LC] PKI vs Non-PKI based trust models
iain at mydex.org
Mon Mar 14 16:34:41 EDT 2011
Hi Bob, that's certainly an interesting line of thought/ potential focus from the Info Sharing work group perspective - whether strategy sub-committee or otherwise.
I've long thought that customer experience/ business case for the individual is a missing link in the whole identity assurance discussion, and am happy to get involved in any work heading in that direction.
On 14 Mar 2011, at 17:15, Bob Pinheiro wrote:
> Regarding U-Prove and failed efforts at consumer PKI:
> For high assurance consumer applications that (should) require strong authentication, such as online banking, payments, access to patient health records and other sensitive personal information, what are the possibilities for doing strong authentication?
> Since PKI doesn't seem to be a realistic possibility at the consumer level (at least not now), it seems that the current choice is limited to one-time passwords, at least for consistency with IAF and NIST 800-63 v1.0.2.
> U-Prove tokens are a potentially viable method for transmitting high assurance claims to a RP for these consumer apps. But even so, the consumer will still need to strongly authenticate to either an identity provider (who issues the tokens), or to a cloud-based active client / token agent / claims agent. Or both (??). With the demise of Cardspace, the use of a self-issued infocard for performing this authentication seems to be out.
> Joni has asked for volunteers for a strategy subcommittee to help Kantara become more effective, attract more members, etc. I'm wondering whether one possible strategic goal for Kantara could be to help transform PKI into something that is practical for use by consumers.
> For example, could Kantara have a role to play in making it practical to provision client-side certificates to consumers, so that websites can enable the use of two-way SSL for consumers who have client-side certificates?
> A second possible strategic direction is to help in getting U-Prove to be implemented in a way that is usable by consumers. There is a related effort in the form of a claims agent working group in Identity Commons, but that is not specific to U-Prove.
> Maybe these thoughts are best discussed in the strategy subcommittee instead, but I just wanted to put this out there and get some sense as to whether anyone thinks these might be reasonable goals to pursue. Or not? Would such goals stray too far from Kantara's mission?
> Bob P.
> On 3/14/2011 10:50 AM, John Bradley wrote:
>> I helped start Xcert software (now RSA KeyOn) 12 years ago to work on federated identity issues using PKI client Auth. Why PKI failed in the consumer/internet space is a big topic.
>> I should also mention that u-prove (zero knowledge prrof) cryptography contains elements of both certificates and assertions. I have limited expectations for any short term traction on that however.
>> On 2011-03-14, at 8:08 AM, Rainer Hörbe wrote:
>>> John, Patrick and I had a discussion about the pros and cons of federation models based on credentials versus assertions. The attached document is a preliminary result with conclusions like
>>> • PKI and non-PKI federation models need to be combined in most cases at higher LoA
>>> • To implement a federation an RFC 3647-style policy is insufficient; A more complete Trust Framework is needed
>>> • Whereas the Higher Education sector favors brokered trust, e-Government and Industry prefer the PKI approach. But it is not a question of one way or the other.
>>> Request for feedback:
>>> I wonder where this discussion should be homed. FIWG, BCTF and TFMM are related, and it is also an extrakantarian issue. Any interest to take over this discussion?
>>> - Rainer
>>> <pki vs non-pki.pdf>
> LC mailing list
> LC at kantarainitiative.org
Co-founder, Mydex CIC
e-mail: iain at mydex.org
This email and any attachment contains information which is private and confidential and is intended for the addressee only. If you are not an addressee, you are not authorised to read, copy or use the e-mail or any attachment. If you have received this e-mail in error, please notify the sender by return e-mail and then destroy it.
More information about the LC