PROPOSAL: RP identifier

[Dick Hardt]

On 22-Oct-06, at 10:44 AM, Martin Atkins wrote:

> Dick Hardt wrote:
>>
>> The issue here is that realm is an overloaded parameter. It is being
>> presented to the user for the user to decide if it wants to IdP to
>> provide similar results to any RP return_to that matches the
>> wildcard. It is also being used by the IdP to uniquely identify  
>> the RP.
>>
>
> Those two seem to be the same thing to me.
>
> The user says to the IdP "Sure, tell this RP that I'm me and don't ask
> me next time." IdP remembers that preference based on the realm. That
> preference is keyed on the realm, and thus the realm *is* the unique
> identifier, in a funny sort of way.
>
> You seem to be conflating "relying party" with "relying party's
> return_to URL". LiveJournal is a relying party with a realm of
> http://*.livejournal.com/; it may well have multiple return_to
> endpoints, but they all belong the same relying party. Any settings  
> the
> IdP keeps for that [user, relying party] pair should apply to all
> endpoints inside that realm. [1]
>
>
> [1] Unless of course an RP with a more specific realm exists inside
> LiveJournal's. It's debatable whether settings applied to LiveJournal
> should be inherited by RPs with sub-set realms. Shall we debate  
> this? :)

[1] is my point. Once the user has agreed to http:// 
*.livejournal.com, an request with a different realm such as http:// 
dick.livejournal.com will be logged into automatically.

The question is, should the IdP treat the realm as a unique id and as  
the user to approve http;/dick.livejournal.com, or does the previous  
realm statement take effect?

-- Dick