• [^] # Re: Pourquoi ?

    Posté par . En réponse au journal Fin de myopenid.com le 1er février. Évalué à 2.

    OpenID prévoit la délégation de l'authentification il me semble. Cela évite justement d’être lié à un service.

    http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication

    3.1.1. Delegating Authentication
    If the End User's host is not capable of running an Identity Provider, or the End User wishes to use one running on a different host, they will need to delegate their authentication. For example, if they want to use their website, http://www.example.com/, as their Identifier, but don't have the means, or desire, to run an Identity Provider.
    If they have a LiveJournal account (say, user "exampleuser"), and know that LiveJournal provides an OpenID Identity Provider and that it'll assert that they control the Identifier http://exampleuser.livejournal.com/ they would be able to delegate their authentication to LiveJournal's Identity Provider..
    So, to use www.example.com as their Identifier, but have Consumers actually verify http://exampleuser.livejournal.com/ with the Identity Provider located at http://www.livejournal.com/openid/server.bml, they'd add the following tags to the HEAD section of the HTML document returned when fetching their Identifier URL.
    <link rel="openid.server" href="http://www.livejournal.com/openid/server.bml">
    <link rel="openid.delegate" href="http://exampleuser.livejournal.com/">
    Now, when a Consumer sees that, it'll talk to http://www.livejournal.com/openid/server.bml and ask if the End User is exampleuser.livejournal.com, never mentioning www.example.com anywhere on the wire.
    The main advantage of this is that an End User can keep their Identifier over many years, even as services come and go; they'll just keep changing who they delegate to.