[security] User directly requet to OP.

[SitG Admin]

>(RP) notifies the user and browser that they may be authenticated by OpenID.

What you're looking for is integrated browser support, everywhere. 
It's tricky, though, to get every major browser to build (into their 
core) support for a minority feature, promising "If you build it, 
they will come . . . "

It's a dream, and developers are correct to insist "FIRST you 
advocates make it popular (support it with add-ons before then), THEN 
the rest of us will recognize the need for it or overwhelming demand 
for it, and put it in."

>The OP provides the browser with user-identifiable information (such as
>cookies).

The "cookies" are currently transmitted in the GET string (or POST, 
with v2.0), *and* crytographically signed by the OP; this is in the 
spec already. Getting site B to create cookies that can be read by 
site A (an additional feature for browsers to support - and, again, 
why?) but not by any other sites, would be much trickier.

>It also informs the RP site that the user has been authenticated, and
>transfers to it the ID, registered date/time, and identifiable information.

Part of this (the registered date/time) has been proposed as 
something akin to CRL's for OpenID's, to indicate when a given 
Identity was consistent for a single user, but it's kept track of by 
the RP, which has no reason to believe what the OP says about how 
long a given user has had a particular ID.

>Because the uniqueness of the ID may be merely guaranteed on the OP
>site,

Is there something about 'http://www.shadowsinthegarden.com/' that 
can be made non-unique by ANY other ID at, say, 
'http://www.malicious-site.com/*'?

>the ID entered by the user (local ID) may differ from that
>announced globally (global ID) (to cope with spam attacks).

You may want to take a look at XRI:
http://www.equalsdrummond.name/?p=150
It utilizes a global registry of alphanumeric ID's to ensure that 
they remain unique.

>The temporal-based uniqueness of the ID can be assured by a domain owner
>who keeps tabs on the date and time when the user starts the
>authentication service.
>This allows for reuse of limited resources, while ensuring the singularity.

Relying Parties (such as Yahoo) are currently using "generation 
fragments" instead of temporal data, such as "/username" for the main 
ID and then appending "#001" for which account held that username, 
with a total ID of "/username#001". Again, allowing anyone *but the 
RP to which an OpenID has authenticated* to be responsible for 
keeping track of this information, creates distrust: for security, 
domains that have been bought up after expiration or OP's that have 
become hostile, NEITHER of them should be allowed to dictate to RP's 
whether or not their assertions are still believable - *especially* 
after the RP has accepted the USER'S assertion that either of those 
parties should no longer be trusted to speak for the user's identity.

Hmm, user-directed blacklisting/whitelisting - now *there's* a thought.

-Shade