Re: Browser ID

On 7/20/11 2:05 AM, Mo McRoberts wrote:
> 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.

What is a profile to you?

I am saying Facebook, Twitter, Google, Your email Provider, Your DNS 
providers, Your LDAP provider etc.. all provide profiles. BrowserID is 
offering yet another profile too.

A profile can be as basic as a network accessible resource the an 
identifier (e.g., email address) is associated with a public key via a 
relation.

> 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…

We already have WebID working with mailto: and acct: scheme URIs. An 
X.509 cert. is a profile in my world view :-)

You +1 Ben's comments, but you are really expressing views closer to mine.

> (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).

People want, need, and will have data spaces. In a data space they can 
make claims about themselves. Claims include associating identifiers 
with public keys. Trouble is the concept of data spaces are not fully 
understood since most assume you cannot be your IdP, that the InterWeb 
is about intermediaries occupying the same layer in the network stack 
due to Web 2.0 flawed practices etc..

> 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...)

To but a long story short, IPv6 will help people understand data spaces. 
WebID can, and will be added to IPSec too. As for BrowserID, once 
there's clarity about email and public key association, it too will work 
with WebID.

Once Ben and Co. release details about Public Key and email address 
association, we'll just knock up a solution to demonstrate my points. 
That's how we prefer to operate.

Kingsley
> M.
>


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Wednesday, 20 July 2011 10:57:20 UTC