"Martin v. Löwis" <[email protected]> writes: > - [must support provider-driven identifier selection] > This is because I want to avoid ugly login boxes in the UI, > and avoid having to type users in their OpenID.
Provider-driven identifier selection is great, for exactly the reason you state here, and I'm glad you have support for it. But it excludes anyone using their own user-controlled OpenID, so *please*, and primarily, support users typing in whatever their OpenID is. > - [must provide a validated email address, either through AX or SREG] > This is because I want to be able to trust the user interface, > and avoid the email verification roundtrip (sparing both myself > the implementation of it, and the user access to his email address > at the time of registration) I don't see why you're setting this as some kind of proviso on properly supporting OpenID authentication. Providing a verified email address is not something you had before. The registration process already knows how to process and verify an email address as specified by the user. The email address you get during registration from the provider is of exactly the same nature as one that the user types in to your web form. So, as far as I can see, adding OpenID authentication is *not* predicated on this at all. I don't understand why this orthogonal issue is being made a condition of standard OpenID support. All we're asking (AFAICT) in this thread is that you separate these two, tackle the streamlining of email address verification as a separate issue, and implement standard OpenID authentication. -- \ “We should strive to do things in [Gandhi's] spirit… not to use | `\ violence in fighting for our cause, but by non-participation in | _o__) what we believe is evil.” —Albert Einstein | Ben Finney _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
