Decius wrote:

Yes. I've wanted to see something like this for quite some time. This sounds very similar to the sort of system I've envisioned. However, I need to read the spec in detail and see if this was implemented properly.

Having now examined the basics -- no analysis, just understanding what they are trying to do -- it seems sound but not as far reaching as what you are talking about. That is deliberate.

This is just a small but well-considered step forward.

2. FOAF sucks. How does the new site actually get meaningful bio information about me when I create my account using this system? This seems like a more important problem to solve. We've been thinking of making a bunch of extensions to foaf here, but we've got a lot of other work to do.

This is not what this system addresses. It is a step in that direction.

What it addresses is just this: I wish to comment on a site that I do not have an account on. Rather than make an account -- yet another identity, etc -- OpenID would let me log into the site with my identity from another site. All that is established is that I am the controller of a url that I specific to authenticate me. This is a very weak guarantee, but with this one can extend to greater things.

It is very similar to the PGP-Signed Comments idea. Enable the preservation of identity across CMS systems.

An example of how I see this working.

If MemeStreams ran an OpenID server

You (Decius) decide to respond to Brad's LiveJournal announcement. Rather than create a JiveJournal account -- a blog, etc -- you log in as www.industrialmemetics.com (as listed in your about page here). LiveJournal checks out that page, and determines that you are who you are if MemeStreams says you are. You log in to MemeStreams, and authorize the MemeStreams' OpenID server to validate your id to LiveJournal. LiveJournal marks your comment as Decius of MemeStreams, or Industrial Memetics, or whatever.

If MemeStreams accepted OpenID

Presumably some of my friends read my memestreams feed on LiveJournal. If they want to comment, however, they either have to join MS or post anonymously. Both has consequences. Easier if they could just say who they are.

If OpenID is exploited

Someone gets to post to MemeStreams under an identity with no reputation. I can log in under any domains or URLs I may have control of. If it is a problem, you keep a list of valid -- or invalid -- OpenID authentication server and discard the rest.

Overall consequence: Does not prevent spam. Does not provide structured mechanism for account creation. Does not enable e-commerce. Does not make toast. Does not overcommit.

3. Email verification. Will LiveJournal validate that they have verified the users email address? Can I trust them?

As they say on openid.net, this is not a trust system. It is just the first step. It makes netizens' lives easier in consolidating the number of identities they need to maintain.

But it seems like something MemeStreams should support, for the scenerios above.

dmv wrote:
If MemeStreams accepted OpenID
Presumably some of my friends read my memestreams feed on LiveJournal. If they want to comment, however, they either have to join MS or post anonymously. Both has consequences. Easier if they could just say who they are.

It makes netizens' lives easier in consolidating the number of identities they need to maintain.

I'm not convinced I agree with that conclusion, as things presently stand.

The fact that you reference this URL doesn't really make my account generation proceedure easier because I can't really rely on it for anything. I could trust livejournal to authenticate you instead of asking for a password, but I don't really see the advantage of that.

Now, I could decide to allow anonymous posts if they offer this kind of authentication. The value of that would be that initially spammers will be unlikely to use this system. However, over time, spam will flow in this way...

But I see the potention over time, if I can rely on this location for detailed bio information about you. I was thinking a useful complement to this would be a service which validates your email address and sends you a digitally signed certificate that your email address checked out. That way you could do it once and post it on this page, and other sites could rely on that instead of having to do it themselves...

Decius wrote:

It makes netizens' lives easier in consolidating the number of identities they need to maintain.

I'm not convinced I agree with that conclusion, as things presently stand.

It is not about account generation. If that's all you care about, then of course we're at a wall. Except the advertising properties of running a OpenID authenticator.

If you talk to Bucy, what you'll hear is a lot of angst about having all of his activities and contents being on remote locations. That memestreams would be a whole lot better if the streams were, or could be, individually controlled. That the reputation system is the feature, not your fantastic web design. Having an ID with the authenticator of his choice is a step in a decentralized proceeding.

You lose lock-in. If that's the problem, it is worth noting. But one of the things that is more appealing about the memestreams community than the rough equivallents (for me) of blogline's clipping service, Yahoo's MyWeb 2.0, del.icio.us, etc etc is the hacker aesthetic of the system. The 'despite being such a small community that makes the recommendation system mostly moot' aspect is overshadowed by 'but it is the right way to do it' attitude.

Now, I could decide to allow anonymous posts if they offer this kind of authentication. The value of that would be that initially spammers will be unlikely to use this system. However, over time, spam will flow in this way...

It is not strictly anonymous, and not strictly non-anonymous. It gives you a framework for establishing posting rights without obligatory account creation. Limit your OpenID acceptance of sites that provide some minimal standard of user authentication. Whatever.

Soooo many sites require registration before using them; I don't even have a good ballpark on the number of web sites I have accounts on. And I'm fucking sick of it. I understand that one wants to establish a user-tracking identity when running a site. But I don't want to have to create a new log-in and password for every silly web forum and newspaper; either I end up using a single password (risk), or a password algorithm (hassle). The risk is that I start to actually care about one of the accounts, and the password is vulnerable by the inexperience of any of the servers I use. We could argue that point, but let's not. Yeah, not having to have a password on memestreams would be nice.

What I'm saying is, gee, wouldn't it be nice to log into sites and blogs by authenticating against MemeStreams (adding MemeStreams visibility). When I post to a big blog, the stuff I post on MemeStreams is a better representation of the content I would like to be categorized for than my personal livejournal. If I am posting in public, an interested reader does not want to drop to a personal discussion of my apartment situation. I would be as happy to be "dm... [ Read More (0.3k in body) ]

dmv wrote:
You lose lock-in. If that's the problem, it is worth noting.

It isn't. I'm not really arguing against doing this. I'm just trying to figure out if this is really the right way.

For example, it seems like you don't really want to authenticate to this system every time. I'd prefer it handed you a cookie, and I embed a web bug from their site in my page. When you hit my site, they'll get their cookie, and the url for the image I'll link will include a hash that uniquely identifies this user/session on my site. I can then make a request to their site with that hash and get back the user details associated with the hash in an easy to parse XML file. When you go to reply to a post is automagically filled out with your details.

Soooo many sites require registration before using them; I don't even have a good ballpark on the number of web sites I have accounts on. And I'm fucking sick of it.

This is a compelling arguement.

Or is account generation so important to you that you can't imagine why someone who finds MemeStreams wouldn't make it a top destination? What is the active/unused account ratio? How many people created an account, posted one comment, and left?

Most accounts are unused by a wide margin.

Email is at least as much bullshit of an authentication method as a URL.

Certainly. I don't authenticate your email address to authenticate you. My purpose is that you can send emails out, and they come from an address, and I want to make sure that address works. Having that take care of once rather then for every site on the net would reduce the hassle associated with making accounts on sites.

Decius wrote:

For example, it seems like you don't really want to authenticate to this system every time. I'd prefer it handed you a cookie, and I embed a web bug from their site in my page. When you hit my site, they'll get their cookie, and the url for the image I'll link will include a hash that uniquely identifies this user/session on my site. I can then make a request to their site with that hash and get back the user details associated with the hash in an easy to parse XML file. When you go to reply to a post is automagically filled out with your details.

I am trying to understand what you are describing. I seem to be failing.

If I understand it, you generate an image request that points to my openid authentication service. In the process of serving that request, I authenticate with my authentication server -- if I have a logged in cookie, this is transparent. You may now query my authentication service about the session tag that you generated and I authenticated to, and it can provide you with details of my account.

Before I argue why that doesn't work, can you confirm that that is what you mean?

My purpose is that you can send emails out, and they come from an address, and I want to make sure that address works. Having that take care of once rather then for every site on the net would reduce the hassle associated with making accounts on sites.

That seems like a worthy project. But I don't see that they need to be tied; or at least, yours seems like a secondary benefit that could be a simple extension. My OpenID server can claim to have an authorative email address, and you can use that whether it is true or not -- if you don't trust that mechanism, either show off the address it is going to with a user modification option, or make them input it despite potentially having it available..

I'm not sure how much of an advantage you could derive from it regarding registration, as I claim that the bulk of that is still for client tracking.

dmv wrote:
If I understand it, you generate an image request that points to my openid authentication service. In the process of serving that request, I authenticate with my authentication server -- if I have a logged in cookie, this is transparent. You may now query my authentication service about the session tag that you generated and I authenticated to, and it can provide you with details of my account.

Before I argue why that doesn't work, can you confirm that that is what you mean?

Yes, thats what I mean. I realize that this would require a centralized openID server rather then a distributed model. This design was very much shot from the hip. I'm just trying to think about different ways that this might work. It would be cool if there was a way to do this without authenticating every time that didn't require a central server, but nothing is coming to me right now. I'll need to think about it.

That seems like a worthy project. But I don't see that they need to be tied; or at least, yours seems like a secondary benefit that could be a simple extension.

I agree.

I'm not sure how much of an advantage you could derive from it regarding registration, as I claim that the bulk of that is still for client tracking.

The advantage would be that I wouldn't have to validate your email. I validate the certificate instead of sending you an email you have to click on. If I trust the certificate authority its just as good, and less hassle.

Decius wrote:

It occurs to me that this could actually be strapped onto the side of the existing openID system...

Certainly.

The OpenID spec says:

It's also recommend that the form field be named openid_url so browsers auto-complete user's URLs between different sites, in the same way the ecommerce world tends to use conventions like "address1" and "address2".

Which I lump into a similar class of hack. I guess I don't understand the multiple icons thing. One could set up an OpenID transaction service: developers target authenticating with the transaction service, and the service handles all of the cross-authentication services. But I am not necessarily sure why one would write or run that service for the public good. It would be like tinyURL or weblogs.com but less visible. And dealing with authentication issues makes it more sensitive -- not because the service would see the users' login information, but it could false authenticate users selectively.

Why multiple icons?

dmv wrote:
Which I lump into a similar class of hack. I guess I don't understand the multiple icons thing. One could set up an OpenID transaction service: developers target authenticating with the transaction service, and the service handles all of the cross-authentication services. But I am not necessarily sure why one would write or run that service for the public good. It would be like tinyURL or weblogs.com but less visible. And dealing with authentication issues makes it more sensitive -- not because the service would see the users' login information, but it could false authenticate users selectively.

It would need to be trusted. As for why someone would do this, its hard to say. Possibly you could run it as a non-profit and accept a minimal tithing from the sites that used it. You couldn't charge too much for it.

Why multiple icons?

As an indicator to the user about whether or not they are logged in.

Decius wrote:

Why multiple icons?

As an indicator to the user about whether or not they are logged in.

I still don't get why a single bug isn't enough. As I understand the system you are talking about:

I hit a webpage meme.com with an image/link to http://centralID/meme.com'sID/sessionID. If I already have a cookie to centralID, the icon shows I am logged in. If not, by clicking the link I am taken to a page at centralID where I do the OpenID handshake, successfully getting me a centralID cookie. This cookie expires frequently.

Why do I need multiple icons?

dmv wrote:
Decius wrote:

Why multiple icons?

As an indicator to the user about whether or not they are logged in.

I still don't get why a single bug isn't enough. As I understand the system you are talking about:

I hit a webpage meme.com with an image/link to http://centralID/meme.com'sID/sessionID. If I already have a cookie to centralID, the icon shows I am logged in. If not, by clicking the link I am taken to a page at centralID where I do the OpenID handshake, successfully getting me a centralID cookie. This cookie expires frequently.

Why do I need multiple icons?

Because if the icon is always the same then you won't know whether or not you need to click on it.

Decius wrote:

Because if the icon is always the same then you won't know whether or not you need to click on it.

I think the multiple states necessary could be handled with a single icon... I can do a demo after my next meeting.