My Suggestion for OpenID 2.1

[Santosh Rajan]

Before I start my suggestion I must say, there may be many ways of doing what ever i have suggested below. So the modalities of achieving the result is not really important. However what is inviolable is the end result.
"The user MUST be able to authenticate himself with OpenID using his email address if he so chooses to".

Here is my suggestion for OpenID 2.1.


Openid foundation MUST host (or delegate to someone) an OpenID XRI Community Server (henceforth to known as OXCS), identified by a business i-name. eg. @OpenID21. For OpenID 2.1

The OXCS MUST allow the creation of FREE sub-names. A sub-name MUST be a unique id generated from an email address.
eg. It could be a base64 encoded hash of the email address.

The OXCS MUST allow sub-sub-names. A sub-sub-name MUST be the preffered name an OP wants to identify itself to the user of the email address, and will be associated with an endpoint.
eg. MYOpenID, GoogleAccount.

Interested OP's MUST register themselves with the OXCS with a sub-sub-name and endpoint.

OXCS MUST allow registered OP's to create (sub-name)*(sub-sub-name) combinations at OXCS.

Registered OP's MUST allow users to authenticate themseleves with their email address.

Registered OP's MUST verify the email address. (This is not necessary if the OP is also the email provider).

Registered OP's MUST create a (sub-name)*(sub-sub-name) at OXCS for every verified email address and ONLY for a verified email address.

Registered OP's must provide at the least the authenticated email address to the RP by either supporting OpenID Simple Registration Extension 1.0 or OpenID Attribute Exchange 1.0.
 
RP's MUST accept an email address as a valid OpenID.

In the case an email address is given, the RP MUST generate an XRI using (OXCS i-name)*(sub-name) combination and perform a discovery on OXCS.

The discovery at OXCS MUST yeild one of the following results.
1) A list of more than one sub-sub-name along with their endpoints.(ie. if the user has registerd with more than one OP). In which case the RP MUST ask the user for the default OP he would like to use at the RP, and save that preferance for future use, and send him on his way.
2) One sub-sub-name with endpoint. In which case the RP can send him on his way.
3) NO sub-sub-name. In which case the RP MUST perform a discovery on the domain part of the email address and send him on his way if the discovery is successfull. Otherwise the RP can take whatever appropriate action he likes.

RP's MUST ensure that the email address returned by the OP is same as the one provided by the user, while verifying the message signature.

[SitG Admin]

>Before I start my suggestion I must say, there may be many ways of doing what
>ever i have suggested below. So the modalities of achieving the result is
>not really important.

 From that perspective, no. From the XRI perspective, generating a
unique ID *from* the E-mail address goes against the idea of
decoupling meaningful identifiers from numeric (machine-friendly)
identifiers; XRI identifiers should be numbers that *noone* will
desire to associate with their Identity, therefore avoiding namespace
conflicts on the social level as different people compete for the
same numbers. (Also note that hashes WILL collide, it's just that
this is supposed to be mathematically improbable as an unsought
outcome.)

>However what is inviolable is the end result.
>"The user MUST be able to authenticate himself with OpenID using his email
>address if he so chooses to".

I'm generally allright with whatever the library does - just keep in
mind that I'll compare the final OpenID to whatever the user typed
in, and possibly parse that to understand just what it is, and then,
if it's not a URL, kill their session and show them an error message.

This is not just a trust issue, it's an identity issue. A website is
open to all, it can contain information *about* the user's identity
without requiring those investigating to identify themselves in the
process. But an E-mail address is closed, it doesn't reveal anything,
it's merely a relay point along the way to communicating with its
owner - for which, you *need* an E-mail address of your own! - who
then knows who was inquiring about them, and when, and may decide to
ignore their request for data, or even feed entirely different
information to different people. Whereas, with HTTP, even a dynamic
website will not know the identity of random visitors, thus it will
not be able to *reliably* control what information is
available/presented to different people.

-Shade
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general