[OpenID] New OpenID Customer Research Activity - Google research on federated login

Thu Sep 25 16:37:18 UTC 2008

On Thu, Sep 25, 2008 at 6:57 AM, Eric Sachs <esachs at google.com> wrote:
>>> In your testing, was the "Email address or OpenID domain" form element
>>> labeled with the openid_url name so that plugins like sxipper or seatbelt
>>> would detect it as an field for an OpenID? Seems like naming it this way
>>> would break the legacy browser form fill...
> Correct, it was not named that way, and for exactly that reason.
>  Unfortunately support both legacy users and "URL" users at the same time is
> really tough.
>>> Also, an the "validated E-mail" address... would it be worth exploring a
>>> way for an OP to have a 3rd-party (the email provider) verified attribute
>>> that the user can submit via AX? This way the user can use whatever OP they
>>> want and just store with the OP the 3rd party verified attribute. The RP can
>>> verify the attribute (via PKI) or some other method without having to force
>>> the user through the password verification process. This would require the
>>> user to go through some process at least once to get the verified attribute
>>> into their OP.  That doesn't really exist yet, but is it something to work
>>> towards?
> I believe this idea has come up in some of the past discussions about
> defining a mapping of an E-mail address to an OpenID URL.  If we
> standardized that, then an RP could do discovery on that E-mail mapped URL
> which would be hosted by the E-mail provider, but then the E-mail provider
> could allow the owner of that E-mail to specify a different OP (or maybe
> multiple OPs) which they trust to assert their E-mail address.  I was not
> part of those discussions, but maybe someone else can jump in to confirm
> whether I described that accurately.

Yes, you could use the e-mail is essentially a reference to a
discovery endpoint for the user's OP and, more generally identity.
Example: user types "user at example.com", and example.com is an EAUT
provider that says transform this in URL to "example.com/user"

Now, the trick here is that you should do the OpenID discovery:
example.com/user could delegate to example.com/login as their provider
and in this case example.com/user would be the user identity, tied to
example.com. However, that is not a requirement. Instead,
example.com/user could use directed identity to point to one or more
providers. In this case, the user would be free to configure other
providers than example.com and choose his identity via OpenID2.0
directed identity at that provider.

The difference is that example.com can introduce a UX to the user in
which they configure alternate providers in terms that non-advanced
users can understand. It will require research and testing, but I
think it is possible. For instance, you could just ask the user "do
you have a myopenid account?" or  "do you use your yahoo! account to
login to other sites?" (these questions would have to appear in some
context that they would appear natural).

Finally, the fact that you can say "your e-mail or domain" allows
advanced users to at least select directed identity model.

The use of the e-mail address does hurt privacy goals that OpenID
could address. But this will require user re-education, and getting
them used to the delegated sign-in model (or to any model that is more
than "type your email and password") seems like the first necessary
step.

>>> For the case of exposing my preferred services via an OP, wouldn't my
>>> OpenID XRDS file suffice?
> On the backends I agree that is how the data would be exposed.  However we
> still need to get OPs to offer a user interface to let user's edit that
> information, and to decide whether it is shared with all RPs, or whether
> some of the information needs more detailed ACLs.  Also, I have heard
> frequent requests from OAuth SPs to have a way to redirect user's to their
> OP with a structured request to add that SP to the user's discovery
> information, with the hope that all the user needs to do in that case is
> click an "I agree" button on the OP site.  The OpenSocial/PortableContacts
> REST APIs seem to be stirring up the most interest in this topic, so with
> luck that may be enough to get some momentum in this area.
>
>
>
>
>
>
> On Thu, Sep 25, 2008 at 5:46 AM, George Fletcher <gffletch at aol.com> wrote:
>>
>> In your testing, was the "Email address or OpenID domain" form element
>> labeled with the openid_url name so that plugins like sxipper or seatbelt
>> would detect it as an field for an OpenID? Seems like naming it this way
>> would break the legacy browser form fill...
>>
>> Also, an the "validated E-mail" address... would it be worth exploring a
>> way for an OP to have a 3rd-party (the email provider) verified attribute
>> that the user can submit via AX? This way the user can use whatever OP they
>> want and just store with the OP the 3rd party verified attribute. The RP can
>> verify the attribute (via PKI) or some other method without having to force
>> the user through the password verification process. This would require the
>> user to go through some process at least once to get the verified attribute
>> into their OP.  That doesn't really exist yet, but is it something to work
>> towards?
>>
>> Thanks,
>> George
>>
>> Eric Sachs wrote:
>>
>> Technically the UI we described in our research document can accept a lot
>> of different identifiers.  E-mail might be the common one, but I also
>> mentioned how an advanced user might enter an OpenID domain using directed
>> identity.  However the RP could allow a vanity URL to be typed in as well
>> which would avoid the need for a browser plugin.  The harder part is how to
>> enable the user to know that option exists.  I mentioned that the phrase
>> "Enter your E-mail address or OpenID domain" appears to avoid confusing
>> average users.  Unfortunately when the OpenID logo was included or the word
>> domain was replaced by URL, then average users did get confused.
>> If an RP accepts OpenID domains for directed identity, then I can't think
>> of a reason they would not also always accept vanity OpenID URLs.  So maybe
>> we should not worry about training really advanced users to know this option
>> exists.  Maybe it would be enough to just make sure there are common open
>> source implementations of this UI style which have this feature built in.
>> Of course, this still leaves the problem of an RP who wants to require a
>> validated E-mail address for a user.  But I think that is an orthogonal
>> issue.
>>
>>
>> On Tue, Sep 23, 2008 at 2:31 PM, SitG Admin
>> <sysadmin at shadowsinthegarden.com> wrote:
>>>
>>> >>  Would it be possible to send the browser a user-side script that
>>> >>  would accept their E-mail address (with the standard field name, to
>>> >>  enable autofill) and attempt to reformat it into an OpenID, possibly
>>> >>  with a popup to show them the transformation and explain that they
>>> >>  should enter this URL in future?
>>> >
>>> >The user-specific URL may be machine-generated and non-mnemonic. It is
>>> >at least usually longer than the domain, and I think users always
>>> >prefer to type less in login boxes. I assume you mean we should train
>>> >them to enter a reference to the IDP.
>>>
>>> No, though this might be better where Directed Identity is in use. I
>>> prefer "real" ("vanity", as max engel called them) URI's, however, so
>>> I visualize users entering, for example;
>>> max_engel at yahoo.com
>>> And then the user-side script pops up an alert when they try to log
>>> in, showing "max_engel" in green, "@" in red, and "yahoo.com" in
>>> blue; and proposing a transformation into this format instead:
>>> http://profiles.yahoo.com/max_engel
>>> Where the red "@" has been removed, the green and blue are the same,
>>> and everything else is black.
>>>
>>> -Shade
>>> _______________________________________________
>>> general mailing list
>>> general at openid.net
>>> http://openid.net/mailman/listinfo/general
>>
>> ________________________________
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>>
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>

-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)