Re: Browser ID

Throwing my hat into the ring. I picked a relevant message to reply to semi-randomly because I had ~50 unread on the same thread. Apologies if I'm duplicating anything.

On 16 Jul 2011, at 22:15, Ben Adida wrote:

> On 7/16/11 9:13 AM, Kingsley Idehen wrote:
>> But everyone has a public profile courtesy of Twitter, Facebook, Google,
>> Microsoft etc.. All of that before we get to FOAF.
> 
> That's not true, and it's certainly not something I want to encourage becoming more true.

+1; there are -vast- numbers of people who don't have, and don't want, public profiles, but still want to log into services.

On the flipside, while more 'serious' services *are* prompting for e-mail addresses even after OpenID or OAuth logins, there are a great many which quite categorically don't, and even many of those which do don't actually use them for anything remotely useful, and so I'd be wary of dismissing them (unwittingly or otherwise) as an aberration: I'll tend towards logging into a “throwaway” site using OAuth to Twitter (e.g., logging into a blog, for example) in no small part BECAUSE doing so doesn't require handing over my e-mail address, getting yet another confirmation e-mail, followed by yet another welcome e-mail, plus an (at least) 50/50 chance of yet another regular “update” e-mail which I need to bother to unsubscribe from, filter, or junk, etc., etc.

BrowserID, for obvious reasons, doesn't do much to solve this. c’est la vie. OTOH, there's nothing wrong at all with a WebID cert containing an e-mail address in the SAN and things which want to resolve that using WebFinger or similar to get a FOAF resource — I'd be _very_ wary of it even being a SHOULD, though, as far as cert-generation is concerned: as soon as WebID got popular, you'd have people screaming blue murder about the fact that all of these sites are getting their e-mail addresses even though it's marked as private in whatever 'profile' tool has generated their FOAF…

(Essentially, all of the "log into sites without a profile" arguments can be transplanted into "log into sites without revealing your e-mail address" arguments: there will always be sites which don't need them, but I'm not sure the requirement of either should be encouraged as a matter of course — deliberately or otherwise — without some very careful consideration).

A separate point: implementing auth in the application layer is a PITA, yes — with caveats. IME it's actually considerably EASIER to do SSL-based access-control in the application layer than it is to do digest auth, because I can rely on the web server to do simple rule-based evaluation for me and just pick up the data it passes on.

That's not to say it's perfect: *well-defined* meta-responses, either at the SSL/TLS level, or as part of the higher-level protocol but which can trigger the UA to do things, would be most advantageous (forcing a log-out to allow an identity switch being the recurring example).

But, web developers don't do digest auth in the application layer not because digest auth is hard in the application layer, but because the user experience of HTTP auth in every browser I can think of sucks so utterly hard that it's not worth it. Web developers, almost exclusively, have opted to go the route of passing credentials as POST bodies (often insecurely) because at least then they'll still have some users.

(Fortunately, the direction of travel is relatively clear: ditch — save for legacy requirements — classic HTTP auth and move to something else which CAN be integrated into the browser across every device that you use without making everybody weep; beyond that, I'm not 100% sure what the answers are just yet...)

M.

-- 
Mo McRoberts - Data Analyst - Digital Public Space,
Zone 1.08, BBC Scotland, 40 Pacific Drive, Glasgow G51 1DA,
Room 7066, BBC Television Centre, London W12 7RJ,
0141 422 6036 (Internal: 01-26036) - PGP key 0x663E2B4A

Received on Wednesday, 20 July 2011 00:06:10 UTC