Stephen, I agree with all your points on OBC, especially the ability to register multiple keys for the same user; keys are cheap and if we used a primary key like an email address instead of a key this becomes easier; of course as we go down this path OBC looks like more like BrowserID implemented tied into the TLS stack (which has positive KFD properties).
As for the signaling topic, Phillip is often discussing the need to express policy in a secure way; DNS and DNSSEC often come up in those conversations -- one could imagine expressing that signaling policy there also. As I write this though it feels odd to see a solution span so many layers, so intimately; that said I have seen (and done) worse ;) On the topic of logging out, I think it's mainly a 99% vs. 1% problem, we being the technological 1% understand the value of closing the browser most users do not, they have been programed for two decades that if they want to stop someone from using their account to logout, not to close all applications and starting all over again. It's common for users to say they feel "trapped" or "lost" when searching for the thing they know must be there and is not, or when it's there but doesn't do what they expect. Having a "logon" concept that has no explicit "logoff" that maps to their views and expectations creates a bad user experience and encourages bad behavior - staying on forever. Ryan -----Original Message----- From: Stephen Farrell [mailto:[email protected]] Sent: Wednesday, February 08, 2012 2:19 PM To: Ben Laurie Cc: Ryan Hurst; Joe St Sauver; [email protected]; Stephen Kent Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the real RPF please stand up?) <no hats and all that> On 02/08/2012 07:19 PM, Ben Laurie wrote: > On 8 February 2012 18:49, Ryan Hurst<[email protected]> wrote: > >> One of the things I like about BrowserID as an approach is that I >> agree with others that the portability of key material in today's >> world is important and by them including the vetting of the ownership >> of an email in their key provisioning workflow they kind of address this problem. >> On the OBC theme, I do like that. (Though I think signalling it via an HTTP authentication scheme would be an improvement as well but that's a detail.) One thing that could be done with OBC would be to not try to move the private keys, but rather provide a standard way to bind different OBC public keys on the user's different devices to the same server account. So, e.g. to associate two devices to the same account the user would be sent to https://example.com/.well-known/obc-bind and after TLS mutual auth would be shown e.g. a short-lived code that could then be entered on a form at the same URL accessed from another device. The UI for that needn't be standard so servers could innovate fairly freely there I think. If the user can bind various devices to the same server account then I think a bunch of account registration and recovery options become available without having to ever move a private key and also without having to bake the registration part into the TLS authentication scheme. It still doesn't do logout though, but personally I don't really get why that's such a deal. I suspect that if we did have logout then malware would just adapt and overall we'd not be that much better off. Maybe I don't get the real requirement there though. > Then you might like the work I did on portability of key material: > http://www.links.org/files/nigori-overview.pdf. I don't get how this differs at all from any centralised login service nor, if its just a key store, why it'd prove any more popular than sacred was, though maybe that's long enough ago that things have changed enough (the EKE patent expired in the meantime at least;-) S.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
