When email providers come online
Brian Ellin
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? 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.
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).
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?
Brian Ellin
JanRain
David Fuelling
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.
Lachlan Hardy
> actual OpenID URL in my own domain -- it's not a Vidoop or
> 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.
I'm pretty sure the current spec doesn't support OpenID delegation,
right?
Michael Richardson
Sure it does. Well, it doesn't explicitly support it, but it doesn't
need to.
http://eaut.org/example/?email=david%40sappenin.com
http://openid.sappenin.com/david delegates to MyOpenID.
Remember, this is email address to url transformation, not email
address to OpenID. It just so happens that it doesn't really make
sense for an OpenID not to be there :)
(by the way, we should probably put in some text somewhere about why
this is needed, considering that mailto:us...@domain.com and http://us...@domain.com
are both valid)
Will Norris
On Jul 31, 2008, at 9:11 PM, Michael Richardson wrote:
> (by the way, we should probably put in some text somewhere about why
> this is needed, considering that mailto:us...@domain.com and http://us...@domain.com
> are both valid)
mailto:us...@domain.com is not a valid OpenID Identifier. Only http(s)
URIs and XRIs are valid.
http://us...@domain.com IS a valid identifier, but it means something
else entirely (but you already know that). Yes, some text might be
good.
Lachlan Hardy
> need to.
>
> http://eaut.org/example/?email=david%40sappenin.com
>
> http://openid.sappenin.com/david delegates to MyOpenID.
Okay, so this is more failed expectation then. I tried a few things.
Using http://erp.gobyairship.com/ redirects me to EmailToID regardless
of my XRDS file (http://lachstock.com.au/XRDS) (which is why I ended
up so confused, because I was using it to test my settings
Using Ma.gnolia leaves me authenticated on their registration page:
http://ma.gnolia.com/register/complete?identity_url=http%3A%2F%2Fopenid.claimid.com%2Flachlanhardy
Using the example (which makes so much more sense) I get this:
http://eaut.org/example/?email=lachlan%40lachstock.com.au
This is a problem for my delegation, yeah? Because it bypasses that
and translates it to the actual OpenID URL.
Ma.gnolia checks against http://lachstock.com.au because that's what
*I* use to refer to my OpenID. It doesn't allow me to login with
http://openid.claimid.com/lachlanhardy because it doesn't recognise
that as belonging to an account.
OpenID Please allows me to login using
http://openid.claimid.com/lachlanhardy because I've already authorised
it against http://lachstock.com.au but it treats me as two separate
identities.
Skitch thinks I'm trying to register a new user, as does PBwiki and Nsyght.
The solution I see for solving this is to support delegation, but
there may be others?
Lachlan Hardy
Michael Richardson
On Aug 1, 2008, at 12:00 AM, Lachlan Hardy wrote:
>
>> Sure it does. Well, it doesn't explicitly support it, but it doesn't
>> need to.
>>
>> http://eaut.org/example/?email=david%40sappenin.com
>>
>> http://openid.sappenin.com/david delegates to MyOpenID.
>
> Okay, so this is more failed expectation then. I tried a few things.
>
> Using http://erp.gobyairship.com/ redirects me to EmailToID regardless
> of my XRDS file (http://lachstock.com.au/XRDS) (which is why I ended
> up so confused, because I was using it to test my settings
erp is a bit old, it's actually pre-EAUT. I should update it to
actually do eaut. http://eaut.gobyairship.com/ , however, uses the
emailtoid discovery API, so it actually performs proper eaut
translations.
> Using Ma.gnolia leaves me authenticated on their registration page:
> http://ma.gnolia.com/register/complete?identity_url=http%3A%2F%2Fopenid.claimid.com%2Flachlanhardy
>
> Using the example (which makes so much more sense) I get this:
> http://eaut.org/example/?email=lachlan%40lachstock.com.au
>
> This is a problem for my delegation, yeah? Because it bypasses that
> and translates it to the actual OpenID URL.
>
> Ma.gnolia checks against http://lachstock.com.au because that's what
> *I* use to refer to my OpenID. It doesn't allow me to login with
> http://openid.claimid.com/lachlanhardy because it doesn't recognise
> that as belonging to an account.
>
> OpenID Please allows me to login using
> http://openid.claimid.com/lachlanhardy because I've already authorised
> it against http://lachstock.com.au but it treats me as two separate
> identities.
>
> Skitch thinks I'm trying to register a new user, as does PBwiki and
> Nsyght.
>
> The solution I see for solving this is to support delegation, but
> there may be others?
If you're using http://lachstock.com.au as your identity url, then
your XRDS document should use that (I see that you have it commented
out).
David Fuelling
Okay, so this is more failed expectation then. I tried a few things.
Using http://erp.gobyairship.com/ redirects me to EmailToID regardless
of my XRDS file (http://lachstock.com.au/XRDS) (which is why I ended
up so confused, because I was using it to test my settings
Using Ma.gnolia leaves me authenticated on their registration page:
http://ma.gnolia.com/register/complete?identity_url=http%3A%2F%2Fopenid.claimid.com%2Flachlanhardy
Using the example (which makes so much more sense) I get this:
http://eaut.org/example/?email=lachlan%40lachstock.com.au
This is a problem for my delegation, yeah? Because it bypasses that
and translates it to the actual OpenID URL.
Ma.gnolia checks against http://lachstock.com.au because that's what
*I* use to refer to my OpenID. It doesn't allow me to login with
http://openid.claimid.com/lachlanhardy because it doesn't recognise
that as belonging to an account.
OpenID Please allows me to login using
http://openid.claimid.com/lachlanhardy because I've already authorised
it against http://lachstock.com.au but it treats me as two separate
identities.
Skitch thinks I'm trying to register a new user, as does PBwiki and Nsyght.
I'm a bit confused. From an OpenID perspective, http://lachstock.com.au and http://openid.claimid.com/lachlanhardy are different identities, even if they're associated with the same account on an OP. So, if EAUT is taking your email address and translating it to a certain OpenID (seems like http://openid.claimid.com/lachlanhardy currently), then RP's that aren't aware of this OpenID will either ask you to create an account, or hook-into an existing one. Am I not seeing the whole picture correctly?
The solution I see for solving this is to support delegation, but
there may be others?
What problem are you trying to solve here? Something relating to Delegation, or something more specific to EAUT?