"Martin v. Löwis" <mar...@v.loewis.de> writes: > > Fred can use his own OpenID ‘fred.example.org’, initially set up > > behind the scenes to delegate to ‘bigcorp.example.com’ as the > > provider. Any time he likes, Fred can *change* which provider is > > actually used for authentication, without changing his OpenID. PyPI > > gets to find out which provider Fred is using for the identity > > ‘fred.example.org’ each time it performs discovery on that identity, > > not before. > > Does that actually work? What actual OpenID provider allows me to > claim 'fred.example.org' as my OpenID?
It's inherent in the protocol, and any standards-conformant provider supports it. If Fred controls ‘fred.example.org’ (i.e. can cause that URL to serve a document of his choosing), then Fred gets to delegate to any OpenID provider, and can change it at any time while keeping the same identity URL. If Albert, on the other hand, doesn't want to set up a URL under his control but instead just use an identity managed by someone else, that's a perfectly valid option: he can use ‘bigcorp.example.com/albert’ as his OpenID, and BigCorp will take care of being the endpoint as well. Albert is not getting any benefit from identity delegation (he's going to have a transition difficulty at some later date when he decides BigCorp isn't serving his identity needs any more), but neither is he required to know about delegation or other protocol details. > Sure, one can use authentication delegation, by means of the > openid.delegate link. However, that still doesn't make the claimed > identifier fred.example.com, but bigcorp.example.com/fred. That's not right (this is what I mean by unnecessarily conflating “who provides the identity this time” with “what is the identity”). The ‘bigcorp.example.com/fred’ URL is *not* Fred's identity in our example, it is only the “endpoint URL”: where Fred has configured his delegation to go. Having control over ‘fred.example.org’, Fred configures delegation, and then can happily forget the endpoint URL in his daily activities. When asked for his OpenID, Fred uses ‘fred.example.org’. Albert, on the other hand, has punted on the whole issue of delegation; he uses ‘bigcorp.example.com/albert’ as his OpenID, because BigCorp causes that URL to be both an OpenID and an endpoint. That's still fine as far as the authentication process is concerned. But the relying party (the party requesting an OpenID from the user; in this case the relying party is PyPI) should not ask the user what their provider is. The user is asked only for their OpenID: Fred will provide ‘fred.example.org’, Albert will provide ‘bigcorp.example.com/albert’. PyPI discovers automatically, each time they use those identities, where the provider is this time by using the OpenID discovery step on the identity they provide. Fred is very happy for this, since he can keep using ‘fred.example.org’ even if he later changes which provider he's delegating to. Albert is very happy for this, because he doesn't have to know anything about “provider” or “delegation” or “endpoint”, he just needs to remember his OpenID. PyPI's user interface becomes simpler, because it only needs to ask the user “what is your OpenID?” and the rest is taken care of by the OpenID protocol implementation. > Please correct me if I'm wrong. I hope that helps. The documents at <URL:http://openid.net/developers/> may be useful if you need more specifics. -- \ “Computer perspective on Moore's Law: Human effort becomes | `\ twice as expensive roughly every two years.” —anonymous | _o__) | Ben Finney _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
