Yet Another Delegation Thread

[Drummond Reed]

+1. In this whole discussion, I have three very strong views (which the
editors can take as input into their call today):

1) If RP discovery reveals an IdP-specific identifier, the RP MUST send it
to the IdP because that's what the IdP needs most to serve the user.

2) If the IdP receives an IdP-specific identifier, the IdP can act on it
immediately without needing to perform discovery. There is no such thing as
a "stale" IdP-specific identifier. The IdP is either authoritative for it or
it is not.

3) Because of (1) and (2), the protocol should make it clear to the IdP when
the IdP is receiving an IdP-specific identifier, i.e., it should not be
ambiguous to the IdP whether the identifier is the Claimed Identifier or an
IdP-specific identifier.

So the whole question in my mind boils down to: even if the RP discovers an
IdP-specific identifier, should the RP *also* send the Claimed Identifier? I
believe there is a strong case for doing so for the reasons discussed in
this thread.

Go for it, editors!

=Drummond 

-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
Of Josh Hoyt
Sent: Thursday, October 26, 2006 8:28 AM
To: Dick Hardt
Cc: Martin Atkins; specs at openid.net
Subject: Re: Yet Another Delegation Thread

On 10/26/06, Dick Hardt <dick at sxip.com> wrote:
> >      * 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.
>
> Which is probably a good idea. :-)
> If the IdP is sending both identifiers in a signed response, then
> they both should be valid.

Requiring this discovery adds another (redundant) HTTP request to the
authentication process, which takes time. I'd like to be able to
improve the "User Experience" by implementing an IdP that would verify
the binding occasionally, but not *every time* the user authenticates.

Josh
_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs