Hello, I need help to make our SSO use case for client certificates known in the upstream browser development communities. Here is the story.
At DebConf we deployed a new experimental single signon system based on ssl client certificates[1], and it works quite nicely. In particular, it allows anyone to create services that authenticate Debian people, with just a few web server configuration lines[2]. I am now aware of any other single sign-on system that has this combination of simplicity, security and usability. There are still a few things that could be better, and I was kind of dreaming that we could build from here[3], just as we recently did a lot of work to ensure that lots of browsers in Debian could work with client certificates[4]. However, there is discussion in the Chrome[5] and Mozilla[6] communities about deprecating client certificate authentication. In those threads, vocal people in support of Client Certificates argued mostly for WebID and seem to have managed to completely alienate the Chrome developers. Other use cases, including ours, were not really represented. My understanding so far is that client certs seem to be better than anything else (one enrollment step, and sites that want to use the auth just add the CA cert and CRL to the web browser configuration). I don't quite mind if <keygen> is removed, as long as there would be a replacement that allows the existence and growth of an ecosystem with shared identification, based on popular standards and easy to use and deploy. FIDO and crypto APIs are mentioned as alternatives which do not seem to be there yet. I appreciate that the Chrome people have said that they intend to wait for an alternative to be viable before removing keygen, although I would want to be sure that they are aware of our use case. I dream of a low-maintenance, established technology that allows a community to set up a central authentication place, and then let a decentralised network of web services grow around that. Client Certificates allow to do that today: it is easy to have a central place authenticating users and enrolling devices, and it is easy to accept and trust those certificates without having to coordinate with the issuing site. I wish that this use case would be explicitly supported. I was happy to see existing, established standards for it. Unfortunately I do not have the time and energy to actively participate in those discussions, so I'm asking for help. To me, sso.debian.org is a side project that I'm working on to support the sites I actually care about: nm.debian.org and contributors.debian.org. So far I have maintained server-side code and patched client software, and now the next step would be to carefully negotiate with upstreams to figure out what can be the future of sso.debian.org. I am losing motivation, because despite all this work, the things I care about are really not progressing. This is a call for help: please help making sure that there are standard ways for mere mortals to setup and maintain central authentication services for their community. I would appreciate being able to just focus on nm.debian.org and contributors.debian.org knowing that I somehow have my back covered on the sign-on side. I see a few things that could be done: - participate in those discussions constructively, being a rational voice showing why and how we use client certificates in sso.debian.org and discussing with the browser communities what could be concrete futures for it. Talking with Chrome developers seems to require a Google account; talking with the Mozilla developers does not: https://www.mozilla.org/en-US/about/forums/#dev-security https://www.mozilla.org/en-US/about/forums/#dev-platform - package and publish django-spkac[7] on a popular platform like GitHub and https://www.djangopackages.com/, with a README somehow explaining the vision and few steps[8] for deploying Single Sign-On for a tech-savvy decentralised ecosystem like ours, and show it as an example of our use case. I want sso.debian.org to grow without me. You may have time, energy, expertise, further and better ideas: by all means go ahead with them. Thank you in advance, Enrico [1] https://wiki.debian.org/DebianSingleSignOn [2] https://wiki.debian.org/DebianSingleSignOn#Documentation_for_web_application_owners [3] http://www.enricozini.org/2015/debian/if-you-know-a-browser-developer/ [4] https://wiki.debian.org/DebianSingleSignOn#Browser_support [5] https://groups.google.com/forum/#!topic/mozilla.dev.security/mr_DoJGOoiA [6] https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/pX5NbX0Xack/kmHsyMGJZAMJ [7] http://anonscm.debian.org/cgit/debian-sso/debian-sso.git/tree/spkac [8] http://anonscm.debian.org/cgit/debian-sso/debian-sso.git/tree/README-spkac.md -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org>
signature.asc
Description: PGP signature