The common case, and when email providers come online
Brian Ellin
I was using myself in the example, but was attempting to illustrate
the case where the user doesn't know anything about OpenID. All they
know is "Cool, I can type my email address to login and it just
works", which is the whole point of EAUT, right? If the user knows
their OpenID URL, then EAUT doesn't need to exist.
So, what is the common case? I propose that it is: 1) Mom visits a
site like magnolia and wants to start using it. 2) She doesn't know
anything about OpenID, goes to the login page, which says "Type your
email to login" 3) She types her email address into the box, and 4)
She keeps clicking "OK" and following the instructions until logged
into magnolia. This involves confirming her email address via the
emailtoid code sent to her inbox.
She won't really know anything about emailtoid other than the fact
that she got an email with a link she had to click, so that she could
get logged into ma.gnolia.com. The return user case is really nice,
as she'll just type her email address into magnolia, and then
emailtoid will log her in.
If her provider (MSN), comes online supporting EAUT she shouldn't have
to do anything to re-enable her account. Obviously, MSN will need to
have a special partnership w/ emailtoid for this to work. If not,
she'll try log in to ma.gnolia.com as usual, she'll click though, and
be logged into a new account with an msn.com based OpenID URL. What
is her recourse, and with whom?
Do you think this is the common case? If so, optimize this flow and
we'll be golden ;)
Cheers,
Brian Ellin
On Tue, Jul 29, 2008 at 10:23 PM, David Fuelling <sapp...@gmail.com> wrote:
> On Tue, Jul 29, 2008 at 5:21 PM, Brian Ellin <brian...@gmail.com> wrote:
>>
>> Greetings EAUTs,
>>
>> A question:
>> What happens when I use brian...@gmail.com via EAUT+emailtoid, which
>> issues me an emailtoid.net identity, and then months later gmail.com
>> implements EAUT?
>
> It depends on how Google implements EAUT, and OP services in general. If
> they allow you to delegate your Google OpenID to another OP, then this may
> not be an issue. Your gmail address could resolve to a Google OpenID which
> could resolve to the OpenID you're currently backing brian...@gmail.com
> with.
>
> But I get your point -- Google, or "insert-email-provider-name-here" may not
> be so nice when they implement EAUT...
>
>>
>> Given the order of operations in the spec, it
>> looks like emailtoid will never be queried again by the RP, and thus
>> the RP won't be able to associate my emailtoid.net URL with my
>> gmail.com URL. This is currently how EAUT adoption is expected to go,
>> but if successful it will make all my accounts at relying parties
>> where I've used my email to login inaccessible.
>
> I'm not so sure -- see my next point.
>
>>
>> For me to be able to log in to those sites again, I will need to do
>> one of these things:
>>
>> 1) Know my emailtoid URL and log in by directly typing that (unlikely).
>
> To be fair, the URL that emailtoid.net returns (for me at least) is my
> actual OpenID URL in my own domain -- it's not a Vidoop or emailtoid.net
> URL. As a user in the predicament you're outlining (where I can no longer
> login to an RP with my email address), I could always go to whatever RP and
> login with my actual OpenID that had previously backed my EAUT email
> address. So, a user relying on EAUT will never get locked out of any RP.
>
> That said, if you sign-in to a bunch of RP's using EAUT with a Gmail
> address, and Google comes along and forces you to map a different OpenId to
> your gmail address, then you would no longer have access to RP's using your
> gmail address -- unless the RP is smart enough to re-associate you somehow.
>
>
> So, from that perspective, this could cause "headaches", but we should be
> clear to agree that EAUT will not contribute to "RP lockout" in a total and
> complete sense.
>
>>
>> 2) Gmail will have to issue (or redirect to) my emailtoid.net URL when
>> resolving my new gmail.com based URL. Either way, gmail now has to
>> know that what my emailtoid.net URL is. It could get it simply by
>> querying emailtoid? Also, I'm not sure gmail would be excited about
>> redirecting my new OpenID URL to an offsite URL, as this could create
>> an open redirect relay.
>>
>> A potential solution:
>> The RP stores the email address instead of the OpenID URL as the key
>> in the database. In this case, the RP code would also need to verify
>> that the claimed identifier returned by the OpenID library matches the
>> URL returned by the EAUT resolution. This solution is also nice, as
>> it would let the user "change" the URL at which services "hang" off
>> of.
>>
>> Thoughts?
>
> This is a really interesting problem to hash through -- the ideas you
> outline above do illuminate potential "headaches" that could occur as EAUT
> adoption increases.
>
> However, it seems to me that RP's should store the OpenID as the primary
> identifier because of the way OpenID trust works. In traditional OpenID,
> you're only trusting your OP with the "keys to the kingdom", as it were. If
> RP's also start using email addresses as "first class identifiers" (see here
> for more on that), then it adds another entity into the trust mix (namely,
> the entity that owns the email address you're using -- e.g., Google).
>
> For example, if an RP is now trusting my Email Address (and a valid
> assertion from any-old OpenID provider), then somebody at my ISP could
> easily adjust my EAUT mapping data and login to my RP sites without me even
> knowing. The way EAUT works now (RP's always rely on an OpenID), if someone
> at Google decided to try to play this trick on me, they would be logging
> into the RP under a different OpenID, and my data is safe.
>
> With all that said, I like the spirit of your idea, but I think it deserves
> more thought since it changes the rules (a bit) of OpenID Trust -- Users
> will have to start trusting both their OP *and* their email ISP provider to
> not do bad stuff on behalf of the user. I'm not quite sold on that latter
> part. I may trust Google not to do the above, but some other ISP, I'm not
> so sure.
>
>
> >
>
David Fuelling
Hi David, thanks for the response.
I was using myself in the example, but was attempting to illustrate
the case where the user doesn't know anything about OpenID. All they
know is "Cool, I can type my email address to login and it just
works", which is the whole point of EAUT, right? If the user knows
their OpenID URL, then EAUT doesn't need to exist.
So, what is the common case? I propose that it is: 1) Mom visits a
site like magnolia and wants to start using it. 2) She doesn't know
anything about OpenID, goes to the login page, which says "Type your
email to login" 3) She types her email address into the box, and 4)
She keeps clicking "OK" and following the instructions until logged
into magnolia. This involves confirming her email address via the
emailtoid code sent to her inbox.
I agree -- this will be a very common flow.
She won't really know anything about emailtoid other than the fact
that she got an email with a link she had to click, so that she could
get logged into ma.gnolia.com. The return user case is really nice,
as she'll just type her email address into magnolia, and then
emailtoid will log her in.
If her provider (MSN), comes online supporting EAUT she shouldn't have
to do anything to re-enable her account. Obviously, MSN will need to
have a special partnership w/ emailtoid for this to work. If not,
she'll try log in to ma.gnolia.com as usual, she'll click though, and
be logged into a new account with an msn.com based OpenID URL. What
is her recourse, and with whom?
I agree - it would be cool if some mechanism existed whereby she doesn't need to do anything. Perhaps the solution here is for "good" email providers to do a EAUT scan of all their email addresses before deploying EAUT. That way, when the ISP goes live with EAUT, people's initial settings would be the same as the day before. Here, the "blissfully ignorant" user doesn't have to do anything different.
That said, however, I can see legitimate business reasons why an ISP would want to deploy EAUT, but automatically have millions of email addresses pointing to their OP and OpenID's (i.e., a "bad" ISP), so I'm not so sure we can rely on ISP's being "good" as outlined in the paragraph above (perhaps this is where connecting with current email providers could be useful).
Do you think this is the common case? If so, optimize this flow and
we'll be golden ;)
Not sure what you mean here.
I think what we're discussing (in general on this topic) is whether or not email addresses should be treated as "1st Class OpenIDs". Not sure if I provided it or not, but this link provides a really nice synopsis of the discussions had on the OpenID mailing lists in 2006/2007 on this very issue. Here's the link: http://wiki.openid.net/Debating_Emails_as_OpenIds
My root objection to treating email addresses as actual openId's (which is what your change would imply) is that it adds a second entity into the OpenID trust chain, which is problematic.
Are these our only two options (either hope that email providers are "good" when they deploy EAUT, or make it so that OpenID RP's utilize an email address on par with the OpenID)?