Auth Discovery and what the relying
>partyneeds to know
>
>Hi Justin,
>
>[not sure why kitten@ is in the Cc. Feel free to drop]
>
>At 08:15 10-05-2012, Justin Richer wrote:
>> "user@domain" represents a person. SMTP, XMPP, SIP, and other protocols have
>&
Hi Justin,
[not sure why kitten@ is in the Cc. Feel free to drop]
At 08:15 10-05-2012, Justin Richer wrote:
"user@domain" represents a person. SMTP, XMPP, SIP, and other
protocols have used this format successfully. OpenID made the
mistake of trying to teach people that "http://domain/user";
Allowing user based discovery is not mutually exclusive with things that
provide browser based help for selecting a IdP.
Forcing a user to type a email address for twitter may also prove unnatural.
More help for the user by their trusted user agent is probably the better way
to go in the long
It's important to remember that these identifiers need to be handled,
seen, and remembered by people. Especially in the long-tail case (which
is to say, IdPs who aren't big enough to get a log in button), users
will need to enter a piece of text into a website to tell the website
who they are.
openID Connect dosen't require a user portion of the identifier to be
discovered and supports a opaque or pseudonymous user_id.
email is an optional attribute that can be returned by user consent.
OpenID 2.0 actively discouraged using email addresses for privacy reasons.
Teaching people to
Hmmm, I see your point but I think that from a privacy PoV revealing the
username to the RP is not good practice, especially not prior to trust being
established between RP and IdP. If the IdP wants to send the assertion in the
authentication statement that is another matter. But you don't want
