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. There's the longstanding usability issue of how users
self-identify. We have taught people over the last 30 years or so that a
format of "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"; could also stand for
them, but people just don't think of themselves in terms of HTTP URLs.
Webfinger came about to address this, and SWD adopted the same pattern.
Account Chooser is a great UI for public, internet-facing websites, but
it's far from universally applicable.
Whether it's good privacy practice or not, the natural pattern for
people to log into a website is to type something that looks like an
email address. Also note that while in many peoples' cases, the
acct:user@domain will match their mailto:user@domain address, but that's
not necessarily true universally. This adds flexibility for allowing a
domain-style identifier to use the same discovery process as a
user@domain-style identifier and privacy-conscious users can use the former.
-- Justin
On 05/10/2012 10:58 AM, John Bradley wrote:
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 enter there email addresses into unknown sites was seen as a
bad thing by many.
WF was started partially as an alternative discovery mechanism for openID to
allow people to enter email addresses to discover there IdP, given a belief
that users could only be asked to enter email and
NASCAR UI was not scalable.
openID is attempting to separately address the NASCAR problem with it's Account
Chooser project to allow the user to configure and control their selection of
IdP without entering info directly into the RP.
For WF/SWD the decision is to enforce discovery by host only or support a user
component so that a email or other service provider could allow per user choice.
I do happen to personally agree that teaching users to give up there email to
random websites is not a good idea, however not allowing a user component in
discovery won't stop RP from asking and removes otherwise useful functionality
and choice fro the user.
John B.
On 2012-05-10, at 1:43 AM, Klaas Wierenga (kwiereng) wrote:
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 rogue RPs
harvesting user names. So instead i have assumed that the domain could be more
specific if needed, i.e. for 99% of the cases example.com would suffice but for
the corner cases I imagine using idp1.example.com and idp2.example.com. But I
understand that in an oauth scenario that may be less pretty.
Klaas
Sent from my iPad
On 9 mei 2012, at 21:31, "John Bradley"<ve7...@ve7jtb.com> wrote:
The lookup is based on the identifier provided by the user. It can have a user
portion in the format of a URI https://j...@example.com ,
https://example.com/john or anything else where you can extract the domain.
The user portion is necessary to allow for per user IdP delegation. Otherwise
only one IdP per host could be supported.
John B.
On 2012-05-09, at 2:42 PM, Hannes Tschofenig wrote:
Hi John,
does the "identifier" contain of a domain part AND a username part or only the
domain part?
That's the crucial question here.
Ciao
Hannes
On May 9, 2012, at 9:20 PM, John Bradley wrote:
For openID Connect we are using the identifier to discover the AS. We refer
to that as an issuer, and perform a second discovery step to get the
configuration (Auth endpoint, token endpoint, user_info endpoint and other
config) for that issuer.
SWD/WF may be used for other things by other protocols, but our use is quite
simple.
I think that is probably the same thing for SASL, but others may think
differently.
John B.
On 2012-05-09, at 1:50 PM, Hannes Tschofenig wrote:
Hi guys,
at the last IIW we had a discussion about SASL-OAuth and what the SASL server
needs to know for discovery.
The discovery discussions around WebFinger go in the same directions.
So, I have been wondering whether we have made an informed decision about how
the discovery procedure is actually supposed to look like.
In my view, the relying party (the client) only needs to know who the identity
provider (the AS/RS) is.
Any other views?
Ciao
Hannes
PS: Please let me know if I should provide more background about the issue.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
Kitten mailing list
kit...@ietf.org
https://www.ietf.org/mailman/listinfo/kitten
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
