<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
For the case of exposing my preferred services via an OP, wouldn't my
OpenID XRDS file suffice? I always looked at the XRDS returned via
discovery on my OpenID as the place to put "personal service discovery"
information. This would allow the RP to find all of my preferred
services (e.g. portable contacts service) and the interact with that
service via OAuth to provide me additional services. Whether I use the
same OP at the Portable Contacts site to authenticate shouldn't matter.<br>
<br>
The key here is that the OP has to allow the user to specify additional
services that should be exposed vis their XRDS file. This should also
work for directed identity and pseudonymous identifiers, as long as the
OP supports XRDS discovery on the pseudonymous identifier.<br>
<br>
Thanks,<br>
George<br>
<br>
Eric Sachs wrote:
<blockquote cite="mid:c4161f510809240920s501b9dfbx383fe1ddff947eaf@mail.gmail.com" type="cite">
<div dir="ltr"><span class="Apple-style-span" style="border-collapse: collapse;">>> I'm reluctant to endorse
an approach which assumes that the user's OpenID Provider is also their
email provider, and I'd prefer to find a solution that does not
relegate email-less OPs to be second class providers.</span>
<div><span class="Apple-style-span" style="border-collapse: collapse;">Max
and I exchanged some E-mail earlier in this thread about some ways I
have experimented with letting "advanced" users enter an OpenID domain
or OpenID URL into the login box instead of an E-mail address. Its is
harder to get good usability data on that, because average users cannot
get through that process, but in a lab setting almost any "advanced"
user with OpenID knowledge can get through it but still complains about
the steps involved. I am talking to a bunch of RPs to try to find one
that would experiment with this login UI, but to also include this
"advanced" option for a URL based identifier. I don't have any
committed yet, but there are some possibilities.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span>
<div><span class="Apple-style-span" style="border-collapse: collapse;">>> This
approach prevents the possibility of issuing RP-specific disposable
email addresses to help prevent spam</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;">I
am not sure why this approach prevents that, however if the IDP gives
out an RP-specific E-mail, then the RP does not have an automated way
to determine if the user has a legacy account with that RP, so it will
have to perform an extra step to prompt the user and ask if they have
one. I expect some combo IDP/E-mail providers might offer the option
for RP specific E-mails, but some RPs have definitely told us they plan
to evaluate the % of users for each RP who finish the signup process.
If the RP find that an IDP who uses this technique has a significant
additional dropoff in the signup rate, then the RP is likely to stop
using that IDP. That won't be true of all RPs, but the big websites
are pretty sophisticated and I've heard this comment a bunch of times.
We may all hate that fact, but we don't have a way to force every RPs
to trust specific IDPs.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;">One
compromise I have discussed with some RPs is to establish a legal
agreement between the RP and the IDP where the RP commits to erasing
the old global E-mail address of the user if the IDP sends both the old
E-mail address and a new RP-specific E-mail address. As a further
step, the IDP could even require the RP to digitally sign all the mail
sent to that RP-specific address with a standard like
DomainKeys/SPF/etc. That gets pretty close to an OAuth like model for
the RP to get a non-transferable right/capability to send mail to the
user. I didn't get enough responses yet to evaluate how likely this
would be to work.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;">>>
and also makes it problematic for the hybrid OpenID+OAuth protocol, as
an OP/SP could only provide services for users who use the OP/SP's
email.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;">That
is going to be true even in the case where the IDP is not the user's
E-mail provider, because the user likely has other OAuth enabled
services which are hosted by someone other then that IDP, such as their
blog, photos, calendar, etc. To give a specific example, a hybrid
Google IDP/SP could not issue tokes for a user's MySpace data, and a
MySpace IDP/SP could not issue tokens for a user's Flickr data. I
think the more general point is that it would be nice if the industry
defined a way for a user to give all their IDPs (E-mail provider,
social network, blog, etc.) a list of the OAuth enabled endpoints that
they are subscribed to, and which they they are willing for the IDP to
send the RP. That would allow a Google IDP to tell an RP that the
user's OpenSocial endpoint is at MySpace, or that the user's photo
album endpoint is at Flickr.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></div>
<div><br>
</div>
<div><br>
<div class="gmail_quote">On Tue, Sep 23, 2008 at 8:53 PM, Allen Tom <span dir="ltr"><<a moz-do-not-send="true" href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<br>
Eric - thanks for publishing the results of the Google OpenID usability
study. I believe that the biggest obstacle preventing OpenID from being
widely adopted are the usability issues which can be painfully
experienced by anyone trying to use OpenID for the first time, and
which are nicely documented in your usability study.<br>
<br>
I'm reluctant to endorse an approach which assumes that the user's
OpenID Provider is also their email provider, and I'd prefer to find a
solution that does not relegate email-less OPs to be second class
providers. The proposed solution also makes the email address the
defacto universal identifier, rather than the OpenID url, making the
OpenID protocol just a browser based email verification system.<br>
<br>
This approach prevents the possibility of issuing RP-specific
disposable email addresses to help prevent spam, and also makes it
problematic for the hybrid OpenID+OAuth protocol, as an OP/SP could
only provide services for users who use the OP/SP's email.
<div class="Ih2E3d"><br>
<br>
<br>
George Fletcher wrote:<br>
<blockquote type="cite">
<pre>I do have a security concern with this approach in that most likely the
AOL user will enter their AOL password because of the past experience.
</pre>
</blockquote>
</div>
I also believe that presenting a username/password combo is a bad idea,
from a security perspective. Based on our own usability studies, Yahoo
users will type in their YahooID/Password.<br>
<br>
That being said, most newer websites allow users to sign in using their
email address, and will reset the user's password via email. As Simon
Willison mentions in his OpenID talks, allowing OpenID for login is
equivalent to allowing a password to be reset via email, just with a
much better user experience.<br>
<br>
Allen<br>
<br>
</div>
<br>
_______________________________________________<br>
general mailing list<br>
<a moz-do-not-send="true" href="mailto:general@openid.net">general@openid.net</a><br>
<a moz-do-not-send="true" href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
general mailing list
<a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a>
</pre>
</blockquote>
</body>
</html>