[sldev] OpenID & SSL certificates

Dzonatas dzonatas at dzonux.net
Tue Oct 2 08:05:54 PDT 2007

Matthew Dowd wrote:
> > I think this discussion is suffering from a serious lack of
> > clarification on exactly what case we are trying to fix. I'd love to
> > hear from Sabin what he thinks of the discussion, and what use cases he
> > is after.
> I'm also getting confused by the subject line too ;-) for me OpenID 
> offers the following potentials (I meant to send a similar e-mail to 
> the list yesterday but forgot to cc the list!):
> OpenID is *part* of the solution for allowing a single userid to be 
> used for multiple services (both from LL and others) - if that was 
> felt to be a desirable option.

I think what is being confused is the thought that the login ID itself 
for OpenID is being directly tied (as part of the security token) to 
access in-world.

You only need a SSL certificate instead of the login (ID/password). The 
login with ID and password is not needed to get in-world.

At this point in time, you won't get far in-world being indentity-less.

LL's proposal is a quick fix to use the technology that now exists in 
the viewer offset the login out of the viewer and take it one step 
towards server side with a temporary (MD5) certificate to login.

I look at this and say we could have the option to take it another step 
further with SSL certificates. One is created already by means of HTTPS 
in the same manner of LL's proposal. The MD5 certificate would allow 
HTTP based logins, but that should be an option, which really does 
appear to be a transitional option just to get over public fear caused 
by the URL pwngd.

Now, we could transition from the proposed embedded login to OpenID.

Notice how the original SSL certificate (mentioned above) is being 
created with the HTTPS connection without ever there being a need to 
login to OpenID or in-world. If you are not that familiar with HTTPS, 
then the SSL certificates are just completely hidden until an 
application (like a web browser) asks you if you want to verify or 
accept them.

We could take this all a step further with OpenID and verification 
brokerage with higher persistence on SSL certificates that get signed by 
a 3rd party.

Yes, OpenID is *part* of the solution, but it does not need to be 
included at first transition. There was the question, however, if we 
should jump ahead on this and skip a transitional.

What I read is if we jump ahead then what would be the justification to 
do such then to just settle for LL's proposal as it now stands?

I asked to allow OpenID and SSL certificates as an option. My 
justification for it is that the technology already exists in the 
viewer, and that being partially because there still needs to be 
implementation to access OpenID and implementation to use SSL 
certificates independently of HTTPS or the web browser. The OpenSSL 
library already exists, so yes we can use SSL certificates 
independently. We already have a web browser to access the basic of 
OpenID, but it is noted many times in this thread how it can be a pain 
to rely on the web browser being present in the viewer. I also stated 
that with higher persistent SSL certificates, the web browser is not 
needed in the viewer as such certificates can be established 
independently of the viewer.

The other thing I see that confuses this thread is that there exists 
lots irrelevant arguments over implementation rather than just focus on 
justification. If we worry too much about implementation and not stay 
focused on the analysis of this (with justification), then we are 
over-planning and wasting time.

Power to Change the Void
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071002/42ca1aa5/attachment-0001.htm

More information about the SLDev mailing list