On 2012-10-03 20:45, Andreas Schwier wrote: > Hmmm, so why would I want an IDP if I could prove my identity > (certificate) and authenticity (client signature in SSL) with the > credentials I have on my card ? > > Is it because SAML is easier to integrate than SSL client authentication > ? Or is it because I want my IDP (e.g. Google / Facebook) to know what > I'm doing ? > > The IDP model is perfect for username / password, but IMHO it's of less > use when you use keys and certificates. In the later case the CA is your > IDP by providing you with a certificate you can use to authentication > towards others (who trust that certificate issuer as they would trust > the IDP). And just lets wait for the first Diginotar incident at an IDP > - ops they've copied our SAML signing keys...)
I think one of the reasons is that the folks that created TSL-client-certificate-authentication forgot to implement logout in a way that works for web applications. They claim that this is a "feature" and that I'm just to understand understand the beauty of it :-) So everybody has to write local IDPs using SAML or cookies even if they have PKI if they want to build anyhthing that looks like a real web app. Then there are of course other a very legitimate uses of IDPs where SAML attributes carry potentially completely alien information like a role which often is less suitable having in a certificate. Andes > > Andreas > > Am 03.10.2012 15:44, schrieb Douglas E. Engert: >> >> On 10/3/2012 5:08 AM, Andreas Schwier (ML) wrote: >>> So why do you think the smart card industry has never managed to get >>> their stuff "web compatible" ? >>> >>> Isn't OpenSC the best example that "Yes, you can access a protected >>> website / webapplication / webservice using a smart card and standard >>> based technology" works ? >>> >>> The issue really is, that the topic at hand (PKI) is way to complex for >>> the average Doe to manage. That's always the downside: Security often >>> means complexity and comes with a price tag. And if it is complex, hard >>> to understand and someone offers some cheaper snake-oil, I probably go >>> for that. >>> >>> Rather than exposing the complexity of the matter with a zoo of options >>> you can choose from, we need to focus on a single generic mechanism and >>> a well designed user experience. >>> >>> It's all there (meaning S/MIME and TLS), it just needs to become a >>> little simpler to manage. So rather than re-inventing the n-solution for >>> Web-ID, SSO or One-Time-Passwords, we - as a community - should improve >>> what is already existing. >> The approach we are taking for SSO is Shibboleth. >> >> http://shibboleth.net/ >> >> Using the X509 login handler: >> >> https://wiki.shibboleth.net/confluence/display/SHIB2/X.509+Login+Handler >> >> OpenSC provides the client cert and key for TLS authentication to the IDP. >> >> Shibboleth is all SAML based, and can work with other SAML based >> services. >> >> Support for OTP or whatever then is only needed in the IDP. >> >> >>> Andreas >>> >>> >>> >>> >>> >>> >>> Am 03.10.2012 11:09, schrieb Anders Rundgren: >>>> http://www.w3.org/2012/09/sysapps-wg-charter >>>> <http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Ew3%2Eorg%2F2012%2F09%2Fsysapps-wg-charter&urlhash=Tqzg&_t=tracking_disc> >>>> >>>> Since the smart card industry have never managed making their stuff "web >>>> compatible" before, I assume they will fail this time as well. >>>> >>>> Anders >>>> _______________________________________________ >>>> opensc-devel mailing list >>>> opensc-devel@lists.opensc-project.org >>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>> > > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
