[sldev] OpenID & SSL certificates

[Dzonatas]

Argent Stonecutter wrote:
> On 30-Sep-2007, at 19:10, Dzonatas wrote:
>> I think that answers Argent's question.
>
> It answers it in the negative, as far as I can see.
>
> It's possible to work around the scheme LL proposed, and restore the 
> status quo.
>
> If they used OpenID, from what Tao and you are saying, it wouldn't be 
> possible to work around it.
>

OpenID or LL's proposal, either one with an SSL certificate option, the 
level of security is a choice by the server's admins. It provides a wide 
range of security levels. That's what I see, and the questions you ask 
depend more on final implementation.

There was an idea I touted about "keys" ooohhhhhhh about almost a year 
ago. People wanted a pretty flexible and easy way to verify users on 
different aspects. It mainly sprung out from the payment flag and CC 
validation.

LL's proposal is actually pretty close to the idea I touted awhile ago, 
but it was used for other purposes than just to login, like one where 
you can use from a prim in-world. I got feedback like, "wow that's 
awesome... can't wait to see you get it done!" "hey everyone, there is 
this cool idea out there." "yo! when is it going to get done?" =)

The basic idea to use some ID to validate a remote key and send back a 
code that only the requester can decipher was not new. The application 
of it did/does have potential to create a start-up over it in cases more 
specific to SL.

My gut must have boiled over about it to where I didn't move on it 
except to give some more use cases.

I believe I looked ahead at the possibilities of the first 
implementation, and just said to myself "yeah... that *was* an awesome 
idea."

Today, if I tried to use the same scheme and merge it with LL's 
proposal, I would say the first initialization of the login certificate 
happens at the same time you download your client. From there, you 
wouldn't need a login password as it exists now. It wouldn't need to 
access any CGI to login. It could do pure SSL from that point forward. 
On this option, you could shave the yak more if you like.

That could be considered an "express" setup, but don't think that would 
be the only setup or only place to get a client. It wouldn't be a 
mandatory setup, but more like the default.

With the login bit out of the way, we could focus on SL group 
permissions. This is where OpenID could take place. Why not actually 
require people to log into their SL groups instead of the login as it 
exists now? Instead of a separate login for each group, OpenID could 
just sum it up to one.

That last point made my stomach feel a little better than last year 
about this whole idea. I actually see this one make it well out of the nest.

Instead of inviting people to groups, why not just send them an e-mail 
with a certificate that allows them access to an SL group?  Automation...

-- 
Power to Change the Void