On 10/3/2012 2:04 PM, Anders Rundgren wrote: > 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 ?
The SSO aspect of the IDP... Using a smart card for every access is an annoyance especially if you have many services a user uses on a daily basis. It also allows for Federations. InCommon for example. >> >> 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 in our case is an enterprise IDP only usable by employees. >> >> 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...) Yes that is a concern. > > 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. Yes, that too. We can map the certificate to an employee and pass employee attributes. Especially helpful if the smart cards are issued by some higher authority. > > 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 > > -- Douglas E. Engert <deeng...@anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
