Re: non-standard login mechanism

2008-11-17 Thread David Fuelling
Sounds like you're simply mapping a SL UUID to an OpenID, so my opinion
would be no, this does not break the spec, so long as the actual OpenID
transaction utilizes the OpenID URL that you have on file in the DB.

This is very similar to the other discussions going on regarding using an
email address in-lieu of a user's OpenID, since in the real world the email
address is the identifier users are arguably most familiar with (currently,
anyway).  Note here that mapping to an email address does not break the
spec, but there is talk of ammending the spec to make email addresses actual
OpenID's.

david

On Mon, Nov 17, 2008 at 1:46 AM, SignpostMarv Martin 
[EMAIL PROTECTED] wrote:

 Just polling for feedback on a bit of a non-standard login mechanism
 I've implemented on my site(s).


 1) a user logs into Second Life, and clicks a kiosk to get a nonced URL.
 2) the user gets a fairly standard OpenID form, submitting their OpenID
 (I'm using the Zend libraries, btw)
 3) once successfully logged in via OpenID, the endpoint and avatar UUID
 are recorded in a db table
 * after this point, the OpenID url will never be entered again (unless
 the user wishes to change their OpenID, or perhaps for circumstances
 where an additional security/paranoia requirement is desired)
 4) the user visit a SLOpenID v3-enabled website, entering their Second
 Life avatar name
 5) the code checks if the name is valid, on file, and if it has an
 OpenID associated
 6) the code then automagically submits the OpenID that is on file to the
 Zend libs (as opposed to accepting a POST or GET value)


 Do note that Linden Lab don't (currently) have an OpenID provider, and
 since I retired SLOpenID v2, I don't believe there are any that cater
 solely to Second Life Residents- though there isn't really much point in
 it any more, considering flickr, live journal and blogger all act as
 providers (all of which are used by Second Life Residents to varying
 degrees).


 The purpose of only using the Second Life name is three-fold:

 1) Residents are familiar with entering their SL name (in either
 first/last format or a single string) in several places throughout
 Linden Lab's presence (viewer, websites)
 2) To strive for a possible standardisation across SL-centric websites,
 increasing people's awareness of possible phishing attacks (see footnote)
 3) To strive for a possible learned behaviour of passwordless,
 transparent OpenID logins in Second Life viewers (OpenID is mentioned as
 a possibility for OGP logins)


 So my question is this: Is using OpenID without the user entering the
 actual OpenID url breaking the spec ?


 ~ Marv.


 *phishing footnote
 If there are no passwords entered on a SLOpenID v3-enabled website,
 there is no risk of the maintainer of said site being accused of
 manipulating users so that they can collect the actual Second Life
 passwords. If the SLOpenID v3 method were to become commonplace amongst
 SL-centric websites, otherwise-uninformed users (e.g. those that use
 SL-centric services) would be immediately less trusting of phishing
 sites that specifically target SL users (e.g. OH HAI! U CAN HAS FREE L$
 IF U ENTER UR PASSWORDS! KTHXBAI MUAHAHAHA)


 p.s. this email has been BCC'd to the OpenID mailing list and LL peeps,
 just in case you're wondering why the text of the email is rather verbose.

 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


non-standard login mechanism

2008-11-16 Thread SignpostMarv Martin
Just polling for feedback on a bit of a non-standard login mechanism 
I've implemented on my site(s).


1) a user logs into Second Life, and clicks a kiosk to get a nonced URL.
2) the user gets a fairly standard OpenID form, submitting their OpenID 
(I'm using the Zend libraries, btw)
3) once successfully logged in via OpenID, the endpoint and avatar UUID 
are recorded in a db table
* after this point, the OpenID url will never be entered again (unless 
the user wishes to change their OpenID, or perhaps for circumstances 
where an additional security/paranoia requirement is desired)
4) the user visit a SLOpenID v3-enabled website, entering their Second 
Life avatar name
5) the code checks if the name is valid, on file, and if it has an 
OpenID associated
6) the code then automagically submits the OpenID that is on file to the 
Zend libs (as opposed to accepting a POST or GET value)


Do note that Linden Lab don't (currently) have an OpenID provider, and 
since I retired SLOpenID v2, I don't believe there are any that cater 
solely to Second Life Residents- though there isn't really much point in 
it any more, considering flickr, live journal and blogger all act as 
providers (all of which are used by Second Life Residents to varying 
degrees).


The purpose of only using the Second Life name is three-fold:

1) Residents are familiar with entering their SL name (in either 
first/last format or a single string) in several places throughout 
Linden Lab's presence (viewer, websites)
2) To strive for a possible standardisation across SL-centric websites, 
increasing people's awareness of possible phishing attacks (see footnote)
3) To strive for a possible learned behaviour of passwordless, 
transparent OpenID logins in Second Life viewers (OpenID is mentioned as 
a possibility for OGP logins)


So my question is this: Is using OpenID without the user entering the 
actual OpenID url breaking the spec ?


~ Marv.


*phishing footnote
If there are no passwords entered on a SLOpenID v3-enabled website, 
there is no risk of the maintainer of said site being accused of 
manipulating users so that they can collect the actual Second Life 
passwords. If the SLOpenID v3 method were to become commonplace amongst 
SL-centric websites, otherwise-uninformed users (e.g. those that use 
SL-centric services) would be immediately less trusting of phishing 
sites that specifically target SL users (e.g. OH HAI! U CAN HAS FREE L$ 
IF U ENTER UR PASSWORDS! KTHXBAI MUAHAHAHA)


p.s. this email has been BCC'd to the OpenID mailing list and LL peeps, 
just in case you're wondering why the text of the email is rather verbose.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs