Subject: [OAUTH-WG] OAuth Discovery and what the relying party needs to know

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 9 May 2012 20:50:10 +0300

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.

---

From: John Bradley <[email-masked]>
Date: Wed, 9 May 2012 14:20:56 -0400

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:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: William Mills <[email-masked]>
Date: Wed, 9 May 2012 11:41:16 -0700 (PDT)

This is going to get fun as we deal with various types of identities.  There was a suggestion at IIW that the workable way to do this for e-mail is via MX records.  What do we do for other types of IDs?

>________________________________
> From: Hannes Tschofenig <[email-masked]>
>To: "[email-masked] WG" <[email-masked]>; [email-masked] 
>Sent: Wednesday, May 9, 2012 10:50 AM
>Subject: [kitten] OAuth Discovery and what the relying party needs to know
> 
>Hi guys, 
>
>Kitten mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/kitten
>
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 9 May 2012 21:42:27 +0300

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

---

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Wed, 9 May 2012 20:41:26 +0200

For SASL-SAML I do something similar, I use the term 'domain', but again this used to lookup the associated SAML IdP

Klaas

Sent from my iPhone

---

From: John Bradley <[email-masked]>
Date: Wed, 9 May 2012 15:31:31 -0400

The lookup is based on the identifier provided by the user.  It can have a user portion in the format of a URI https://[email-masked] , 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.

---

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Thu, 10 May 2012 07:43:20 +0200

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

---

From: John Bradley <[email-masked]>
Date: Thu, 10 May 2012 10:58:35 -0400

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.

---

From: Justin Richer <[email-masked]>
Date: Thu, 10 May 2012 11:15:46 -0400

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:
>> On 9 mei 2012, at 21:31, "John Bradley"<[email-masked]>  wrote:
>>

---

From: John Bradley <[email-masked]>
Date: Thu, 10 May 2012 12:25:42 -0400

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 term.  
In the short therm almost anything is better than users current practice of entering there email and password directly into random sites.  

It is reasonable in the IMAP case where the client already has the email to use that to start discovery for the Authorization server for that identifier.

John B.
On 2012-05-10, at 11:15 AM, Justin Richer wrote:

> 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
>

---

From: SM <[email-masked]>
Date: Fri, 11 May 2012 00:19:02 -0700

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"  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 strings industry probably have some reason to believe that people 
think of themselves in terms of domain names.  Some people think of 
the other person in terms of "what's your [insert social 
network]?".  There are several specifications which reference rfc822 
identifiers.  The interesting point in the above is what will be 
people's expected behavior while taking into account the usual 
technical limitations.

Regards,
-sm

---

From: William Mills <[email-masked]>
Date: Fri, 11 May 2012 08:08:31 -0700 (PDT)

Kitten is in the CC list because this applies to the discovery needs of the OAUTH SASL draft.

> From: SM <[email-masked]>
>To: Justin Richer <[email-masked]> 
>Cc: [email-masked]; [email-masked] 
>Sent: Friday, May 11, 2012 12:19 AM
>Subject: Re: [OAUTH-WG] [kitten] OAuth Discovery and what the relying partyneeds to know
> 
>Hi Justin,
>
>> "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 strings industry probably have some reason to believe that people think of themselves in terms of domain names.  Some people think of the other person in terms of "what's your [insert social network]?".  There are several specifications which reference rfc822 identifiers.  The interesting point in the above is what will be people's expected behavior while taking into account the usual technical limitations.
>
>Regards,
>-sm