[OpenID] [LIKELY_SPAM]Re: [LIKELY_SPAM]Re: [LIKELY_SPAM]Re: Combining Google & Yahoo user experience research

[Chris Messina]

On Wed, Oct 22, 2008 at 4:29 PM, Martin Atkins <mart at degeneration.co.uk> wrote:
> Chris Messina wrote:
>>
>> This may not be ideal or what's expected, but it's a practice that exists.
>>
>
> Indeed, and it is in fact allowed by the OpenID 2.0 spec if you interpret it
> as the following, rather bizarre, interaction:
>
>  * RP requests verification of http://id1.example.com/
>  * OP ignores that request, but then...
>  * OP sends RP an "unsolicited positive assertion" for
> http://id2.example.com/ .
>
> Section 10 of the 2.0 spec says that RPs SHOULD accept unsolicited positive
> assertions.
>
> In practice, most RPs respond to an unsolicited positive assertion the same
> way as a solicited one, but depending on the use-case this might not make
> sense.
>
> While I don't dispute that it's correct per spec, I think it does make for a
> confusing user experience if there's already an active session for the
> "wrong" account, and it also causes trouble for users of delegation since if
> Yahoo! verifies the wrong identifier the delegation will be wrong and the
> RP's OpenID library will (or rather, should) treat it as an invalid
> assertion.
>

Delegation seems possible with email identifiers, but unlikely.

I also think that the case of account collision (where a user attempts
to login to an RP with an identifier from an OP where active session
has been established for a different user), is both likely and common.
However, in terms of user experience, there are a number of things
that could improve this flow:

1. the OP might require the user to enter a 4-digit PIN to confirm
account ownership. This isn't required in OpenID, of course, but would
be a convenient way to disallow anyone besides the account holder from
letting the OpenID verification/assertion go through. Vidoop of course
offers the image shield as another alternative, but once you're signed
in to your account, having a lesser/more convenient second factor to
confirm authentication might be wise, especially in shared computing
environments (i.e. schools, libraries or the Apple store).
2. should a collision occur, there is a possibility that the end user
will actually sign off from the current session ("Oh, that's not my
account... hmm") and sign in under their own account, and complete the
return_to RP with either the original identifier as the claimed
identifier, or with a directed identity. In either case, this flow
would be rather intuitive, but also supports the case where the
presented email identifier is not [always] returned to the RP.

Chris

-- 
Chris Messina
Citizen-Participant &
  Open Technology Advocate-at-Large
factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is:   [ ] bloggable    [X] ask first   [ ] private