Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I believe Andrew's answer is quite accurate. The only thing I can add is a little bit about how the v2.0 spec ended up the way it did, allowing the provider to choose to not work with delegation. I think one of the motivators was the server-directed identity selection, in which the user just supplies "yahoo.com" (or click the Yahoo button), and then their chosen ID comes back from the server in the id_res response. This also allows the server to do things like offer a choice of which ID to send (as Yahoo does) or send a unique identifier to each RP (as Google does).</p> <p>It also means that all the necessary information is in an <code>id_res</code> response, which means the RP doesn't need to store state from its <code>checkid</code> request in order to process the response. In fact, a provider could send an <code>id_res</code> response directly to the RP without the RP initiating it with a <code>checkid</code> request at all.</p> <p>A v1.x provider was completely unaware when delegation was evening happening. This design prevented a provider from even choosing to not support delegation, but also made for some UI problems; it would be asking if you wanted to provide the "joe.coolprovider.com" ID when you were actually using your delegated "joesmith.org" ID.</p> <p>So, there's the tradeoff. Delegation is still possible, so the hope was that users who really want delegation (which, let's face it, is going to be dwarfed by the number of users from these big sites) can choose providers that offer the features they need. (In other words, let the market fight it out.)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload