[OpenID] OpenID Registration Scenario

[Peter Williams]

Ill advise the openid community Not to set its goals so low as to equate openid as that which one should associate with those sites that today do email auth (as proof of ID control).

A decade ago , netscape+verisign issued over 1million consumers with ID credentials (ssl client certs also capable of signing netscape email). Only proof of control over an email account was required.

This did Not engender adoption of client certs, contrary perhaps to intuition.

-----Original Message-----
From: "John Wang" <jwanggroups at gmail.com>
To: "Immad Akhund" <i.akhund at gmail.com>; "OpenID - General" <general at openid.net>
Sent: 7/11/07 8:25 PM
Subject: Re: [OpenID] OpenID Registration Scenario

On 7/11/07, Immad Akhund <i.akhund at gmail.com> wrote:
>
> As to a local password, I would instead just use email as an account
> > retrieval mechanism if needed.
> >
>
> Assuming they have lost control of their previous openid; after they
> receive the account retrieval email wouldn't it make sense for them to setup
> a username/password to retrieve their account or would you think they should
> have a second openid ready to associate their account to?
>

I think this is a concern. The email address can be used to retrieve the
account but some other authentication method would be needed for the user to
access their online profile again. It seems to make sense to have a fallback
local authen system so the user experience can be cleaner (no third party OP
required to reestablish user access) and because at this time, it's
uncertain how successful OpenID will be.

I personally think using a local fallback in the form of an optional
> username/password makes sense. But it's really up to the RP and its needs.
> Having a "captiveOpenID" doesn't make sense as a solution to this scenario
> since they would have to authorize that with a username/password anyway (I
> may be missing the meaning of captiveOpenID).
>

When I use the term Captive OpenID, I mean an OpenID system that is run by
the RP. When the RP and the OP are the same, it is possible to set up the UI
to look exactly like username/password and do the OpenID authen behind the
scenes and there is no need for or indication to the user that OpenID is
being used. It seems like if you restrict local "usernames" to not have
periods, a username can never be mistaken for a fully qualified OpenID uri
and the RP can just append their own domain name to the username to create
the user's fully qualified captive OpenID uri.

I've been thinking of having the local username/password be such a "Captive
OpenID" under the covers but not necessarily known to the user. Advanced
users can may be able to use the Captive OpenID at other sites by appending
the RP/OP's domain name but there's no need for the average user to know
OpenID is being used under the covers, especially if they won't care and it
would slow adoption for the site.

To make Captive OpenID work smoother, I'm also thinking of an OpenID
authentication server SDK that will remove the need to make a HTTP redirect.

-- 
John Wang
http://www.dev411.com/blog/