>(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 _______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security
