Ma.gnolia Update and UX Notes

[la...@ma.gnolia.com]

I've officially announced Ma.gnolia's support for EAUT (http://
ma.gnolia.com/blog/2008/08/05/an-email-address-is-a-person-too) after
working out some ux issues experienced by some folks on this list. I
think it will be a common pattern, so it might be good to review and
document the issue we experienced and solution we applied.

The problem arose when a member who had already registered with
Ma.gnolia tried to sign in using EAUT with the email address they had
registered with us:

Since we were doing a standard EUAT with emailtoid.net as our
fallback, they got sent to emailtoid.net.

There, they verified their email address, and were automatically given
an emailtoid OpenID and sent back to Ma.gnolia.

We hadn't ever seen that OpenID before, so we asked them to associate
it with an existing Ma.gnolia account, which they could not do since
they didn't have a legacy Ma.gnolia password.

After consulting with Chris, the obvious solution was to first check
our own accounts for an OpenID associated with an email address, send
the member to their registered OpenID provider if they have one, and
only then go through the standard EAUT process.

Hope this bit of UX debugging helps out future implementors, and I'm
happy we could finally, officially roll out our EAUT support.

[David Fuelling]

On Wed, Aug 6, 2008 at 2:12 AM, la...@ma.gnolia.com <la...@ma.gnolia.com> wrote:

I've officially announced Ma.gnolia's support for EAUT (http://
ma.gnolia.com/blog/2008/08/05/an-email-address-is-a-person-too) after
working out some ux issues experienced by some folks on this list. I
think it will be a common pattern, so it might be good to review and
document the issue we experienced and solution we applied.

Congrats on the official EAUT release!!  You guys are awesome!
 

The problem arose when a member who had already registered with
Ma.gnolia tried to sign in using EAUT with the email address they had
registered with us:

Since we were doing a standard EUAT with emailtoid.net as our
fallback, they got sent to emailtoid.net.

There, they verified their email address, and were automatically given
an emailtoid OpenID and sent back to Ma.gnolia.

We hadn't ever seen that OpenID before, so we asked them to associate
it with an existing Ma.gnolia account, which they could not do since
they didn't have a legacy Ma.gnolia password.

After consulting with Chris, the obvious solution was to first check
our own accounts for an OpenID associated with an email address, send
the member to their registered OpenID provider if they have one, and
only then go through the standard EAUT process.

This makes sense from a UX perspective, but it has the potential to break the EAUT protocol (I only say that because you mentioned that you're doing an email check on ma.gnolia *before* you do any EAUT processing).

What's interesting is that this particular use-case is unique to users who have *not* pre-configured either a URL Template or a Mapping service (i.e., EAUT Discovery produces no XRDS for the specified email address).  In this case, I think your flow is perfectly fine -- arguably the OpenID that ma.gnolia has associated with an email address is the best OpenID to map to, since there is no other indication.

However, if somebody (like me) has actually enabled EAUT on their email address, then Ma.gnolia should respect that EAUT translation -- it's the best indication of the particular URL that a user wants to map his/her OpenID to.

It's a pretty discrete point, but important I think for proper EAUT implementation.  So, it seems like the following flow would be best (in general):

1. User enters email address.
2. Use EAUT to lookup their XRDS info.  If found, then always respect the URL Template or Mapping service.  This is a direct indicator that the user/ISP wants to map that email to a particular OpenId.
   
3. If XRDS not found, then us a default mapping service -- in ma.gnolia's case, the default mapper is ma.gnolia, perhaps followed by emailtoid.

That said, the above flow demands a minor UX adjustment for the particular following case (the one where a user *does* have EAUT configured:

1. User has mapped email 'us...@example.com' to the OpenID 'http://new.example.com'.
2. User has an existing account at ma.gnolia.com with the OpenID 'http://old.example.com'.
3. User logs into ma.gnolia.com with her email address, which translates to 'http://new.example.com'.
4. ma.gnolia would ordinarily think this is a new account (it has never seen the OpenID 'new.example.com') -- however, magnolia should link this OpenID to the existing account ('old.example.com), which can be found via the email address. 
   
5. This UX would require a secondary login with the existing OpenID ('http://old.example.com'), but once an association was made with both openid's, then magnolia could automatically associate both OpenID's to the same account.

Alternatively, ma.gnolia may require this dual OpenId association to occur manually (it's what I had to do when I logged into magnolia, so I know it's already supported).

Anyway, I think it's important for RP's to respect EAUT first, then use their own information for email addresses that don't overtly support EAUT.  It wasn't clear to me whether or not your solution does this, but I think doing things this way would provide the same UX for the user you wrote about (with no EAUT info) while respecting EAUT properly.

Thoughts?