ben+python at benfinney
Nov 14, 2009, 7:53 PM
Post #10 of 31
(2673 views)
Permalink
|
"Martin v. Löwis" <martin [at] v> 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 [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com
|
1
