[OpenID] Combining Google & Yahoo user experience research
George Fletcher
gffletch at aol.com
Tue Oct 21 17:54:15 UTC 2008
Martin Atkins wrote:
> Johnny Bufu wrote:
>
>> On 14/10/08 03:14 PM, Martin Atkins wrote:
>>
>>> I think the "resolve an email address to an XRDS document" step is the
>>> hard part.
>>>
>> [...]
>>
>>> * Do XRDS discovery at a URL formed by taking the email address
>>> domain and adding "http://" to the start and "/" to the end. This
>>> requires that whatever's declared in the XRDS file be able to map the
>>> username part onto a URL
>>>
>> Why is this part required at all, given the (mandatory support for)
>> OP-Identifiers in v2?
>>
>>
>> RPs can, using no more than OpenID 2.0, perform OpenID discovery on
>> http(s)://user at example.com/ and obtain an OP-Identifier, e.g.
>> https://example.com/op/. (RPs really don't need a user-specific
>> identifier at request time.)
>>
>> It is then trivial for the OP to figure out the username / identifier
>> *post* authentication.
>>
>>
>
> I think it'd be pretty confusing and non-obvious if I typed in
> something at example.com but, because of an existing session, I actually
> ended up claiming somethingelse at example.com. This could arise for a
> number of reasons, including but not limited to a given person having
> several email accounts or several users sharing the same computer who
> have not yet discovered the wonders of separate local user accounts.
>
> We should never ignore any part of what the user enters. If they just
> enter their OP's domain, then the above is fine.
>
I don't think the OP should ignore it... but if the user is already
signed into the OP with a different identifier, then the user should be
presented with the situation (you are currently signed in with x but
specified y) and be allowed to chose what to do next (either continue
with x, or logout x and attempt to authenticate y).
Also, if the RP is passing the whole "email address" to the OP, does
that just go in the openid.claimed_id parameter of the authentication
request? I'm assuming that "Normalization (section 7.2)" will have no
issues with resolving http://user@example.com?
I did some simple testing and at least one major site doesn't handle the
current "Accept: application/xrds+xml" header on requests to
http://user@example.com.
I'm guessing we'd need some detailed "best practices/implementation
guidelines" to define the constraints for this solution.
Thanks,
George
More information about the general
mailing list