3) santosh.rajan.myopenid.com
4) http://santosh.rajan.myopenid.com
5) http://myopenid.com/santoshrajan
Now (1) and (2) are not practical so we will eliminate that. (3) is the best
option as I see it. I know you will say that there is no difference between
(3) and (4). But if you are an average user it makes a huge difference.
While it is true that 3 will default to 4 (and it would be nice if
users had a way to specify 6, i.e. httpS), this is primarily for
discovery and internal distinction - since users cannot be known as 3
(because it is not a legal URI), there is no risk of confusing an
entry for 4 with an entry for 3, and RP's can trivially omit the
'http://' before users' ID's, so that, to the average user, they DO
show up as 3; they need never know they are being treated any
differently. (This is most apparent in the case of XRI, where the
user's unique Identity might be '=!F83.62B1.44F.2813' even when
'=drummond' is what appears to users.)
When you see actions attributed to OpenID users at some RP's site,
there might be a little "Secure" logo/label to show off that the user
took THAT action when authenticated over SSL.
One of the #options I had planned was to use HTTPS instead of HTTP
where the user added '#secure' to their URI; this wouldn't help with
attackers hijacking DNS, but it would help the user to not
accidentally go to the wrong server. (I said 'help', not 'ensure';
users would still be responsible for listening to their browser's
warnings about bad certificates, and probably still ignore them.)
So the puzzle is why wasn't (3) chosen as the Openid instead of (4) and (5)
Because browsers need to know where they're looking for the resource;
HTTP is merely one protocol, others can be launched through the
browser (FTP and TELNET come to mind).
-Shade
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
