Re: [OAUTH-WG] [kitten] OAuth Discovery and what the relying partyneeds to know

"Klaas Wierenga (kwiereng)" <kwiereng@cisco.com> Thu, 10 May 2012 05:43 UTC

Return-Path: <kwiereng@cisco.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1C321F8516; Wed, 9 May 2012 22:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.136
X-Spam-Level:
X-Spam-Status: No, score=-7.136 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLkXAqzinH9H; Wed, 9 May 2012 22:43:43 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5734721F850B; Wed, 9 May 2012 22:43:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kwiereng@cisco.com; l=3000; q=dns/txt; s=iport; t=1336628623; x=1337838223; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=C0qNzd4rOIfUWlcCImjIJM4Hx5K/KuEKMYPxiz7LTNw=; b=Ex35xoLPTGLW69PwtJ2vKJfUYRSSNuGh9vkXcTgIcKOabtHIW4ZUiTJV WkTMYs7/ACPdH7p9zLv1hXvSKVeX7p7M0i694+t1OKk2a1qu3FOVy4G6R iT5LBf+XaJtGRIcRFvDbcxIScn3v02ZDnbQkfdG6xVzPJrEmSPxtGS1sE k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmMHADlVq0+Q/khL/2dsb2JhbAA7CbEcAQEGghUCgQeCDAEBAQMBAQEBDwEnNAsFCwIBCA4KLicwAQEEEyKHZwULmwSgG4sNEIU2YwSVfYERjUYngUKCaw
X-IronPort-AV: E=Sophos;i="4.75,561,1330905600"; d="scan'208";a="137507378"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 10 May 2012 05:43:20 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4A5hKxF021503; Thu, 10 May 2012 05:43:20 GMT
Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 May 2012 07:43:20 +0200
Received: from 144.254.74.76 ([144.254.74.76]) by XMB-AMS-101.cisco.com ([144.254.74.76]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 May 2012 05:43:19 +0000
References: <40FC97F0-B72C-47F4-8206-590BA365997A@gmx.net> <5ECED997-49B8-4550-B79A-CF121FCD1AF9@ve7jtb.com> <9F541ABD-23C0-4592-BC8C-7B7E7CC620CB@gmx.net> <81091A66-03C3-4085-A840-BEC1BBF48161@ve7jtb.com>
Content-Transfer-Encoding: quoted-printable
From: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Thread-Topic: [kitten] [OAUTH-WG] OAuth Discovery and what the relying partyneeds to know
Thread-Index: Ac0ub84LsNJtIDyjT8mLTat+qsjtww==
In-Reply-To: <81091A66-03C3-4085-A840-BEC1BBF48161@ve7jtb.com>
Message-ID: <A5BFAE4A-5FF2-4E0C-BE49-A04AA9AC9A98@cisco.com>
Date: Thu, 10 May 2012 07:43:20 +0200
To: John Bradley <ve7jtb@ve7jtb.com>
MIME-Version: 1.0 (1.0)
X-OriginalArrivalTime: 10 May 2012 05:43:20.0736 (UTC) FILETIME=[CEADDA00:01CD2E6F]
Cc: kitten@ietf.org, oauth@ietf.org
Subject: Re: [OAUTH-WG] [kitten] OAuth Discovery and what the relying partyneeds to know
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 May 2012 05:43:44 -0000

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" <ve7jtb@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://john@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
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten