Yet Another Delegation Thread

[Josh Hoyt]

On 10/25/06, Martin Atkins <mart at degeneration.co.uk> wrote:
> > Then why send it?
>
> That's what I've been asking all along! :)
>
> What exactly do we imagine the IdP doing with the claimed_identifier?
> The main answer I've seen anyone post so far is that the IdP will use it
> to greet the user

The primary reasons that I think sending the claimed identifier are useful:

  1. The relying party no longer has to be responsible for managing
state for this transaction

  2. The IdP can use the claimed identifier to choose an appropriate
persona and other behaviour, such as auto-approval differently for
different identifiers

  3. The user experience can be more consistent. Even if the IdP
greets you as Martin, if you use more than one identifier with that
IdP, it's a much better experience for the IdP to remind you when you
are making a decision which identifier you will actually be logged in
as. The IdP can't do that if it gets only an IdP-specific identifier.

The primary reasons that I think it's useful to send the IdP-specific
identifer as well:

  1. The IdP is not *responsible for* doing discovery, so:

     * It's possible to be more efficient, since discovery is not
duplicated by the IdP and RP. This is mostly just a nice side-effect
and is not the primary motivation for my support.

     * there is one less place where spoofing discovery is a valid
attack. If the relying party is not checking the IdP-specific
identifier, compromising an IdP's discovery is sufficient to hijack a
user's identifier.

     * If the IdP-specific identifier is not checked by the relying
party's discovery, the IdP MUST do discovery on every request to
ensure that it's not making an assertion based on stale information.

  2. Checking the response is more strict, since ALL of the discovered
information must be verified.

Put these together, and it's my case for sending both identifiers.

Josh