Re: [OAUTH-WG] draft-jones-appsawg-webfinger-04

Hannes Tschofenig <hannes.tschofenig@gmx.net> Tue, 08 May 2012 14:55 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 58D4C21F8657 for <oauth@ietfa.amsl.com>; Tue, 8 May 2012 07:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 byzuqM2mrfU4 for <oauth@ietfa.amsl.com>; Tue, 8 May 2012 07:55:14 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 50B1821F8645 for <oauth@ietf.org>; Tue, 8 May 2012 07:55:14 -0700 (PDT)
Received: (qmail invoked by alias); 08 May 2012 14:55:12 -0000
Received: from unknown (EHLO dhcp50-94-118-50.hil-dcaaedt.dca.wayport.net) [65.89.200.2] by mail.gmx.net (mp032) with SMTP; 08 May 2012 16:55:12 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19CNEw774lCiM02z77/BCAeYv4Yx5gExuXcDTIw0S KwSwameQBg7VTw
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
In-Reply-To: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com>
Date: Tue, 8 May 2012 17:55:00 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <7C8C2724-8BB3-4B45-9144-D2645E3D0B4D@gmx.net>
References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com>
To: Murray S. Kucherawy <msk@cloudmark.com>
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: "oauth@ietf.org WG" <oauth@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [OAUTH-WG] draft-jones-appsawg-webfinger-04
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: Tue, 08 May 2012 14:55:15 -0000

Hi Murray, 

it is great to see that you are pushing things forward here but I believe you are going a bit too fast. 

From the comments I have seen so far I got the impression that many got confused by UR schemes: mailto: and the acct: are different. 
The discussions around XML vs. JSON are unfortunately also hiding the real important discussion, namely privacy. 

We are actually building, without further thinking about it, a mechanism that offers worse privacy properties compared to what we have in other protocols today.

See this in terms of the interaction between a relying party and an identity provider then other IETF protocols today (e.g., AAA) does not require the relying party to see the username part of the identifier. In fact AAA offers various mechanisms to hide the username component to the relying party since it is really only needed by the identity provider.

So, I would encourage the group to think about how to accomplish equivalent functionality without unnecessarily revealing identifiers to parties that are not supposed to get them.

I also think it is useful to think about the bigger picture,namely the integration with other protocols (such as OAuth). This will in most cases be needed when you actually fetch the data that is behind the discovered URIs. Assuming that all information is public anyway is not realistic and protocol design has to work with the difficult assumptions (not with the simplest). Furthermore, the usage of CORS is completely confused in the document. 

Hence, I heavily object to use this document as a starting point. 

I may also be the case that WebFinger is not the right tool for something like OAuth (and for discovery of protected resources altogether) since we do not want to design a solution that on one hand allows us not to reveal any user identifiers to the relying party (the client in OAuth) based on the current design and then completely destroy these properties when we add the discovery mechanisms in front of it. 

Ciao
Hannes

PS: I met some W3C folks last week and they mentioned that we should also take a look at Web Intents. I have not done that yet and do not know how suitable the W3C developed mechanisms therefore is. 

On May 4, 2012, at 8:31 PM, Murray S. Kucherawy wrote:

> The above-named draft has been offered as the recommended path forward in terms of converging on a single document to advance through appsawg.  The conversation I saw this week in that regard has seemed mostly positive.
>  
> Please review it, or at least the diff, and indicate your support or objection on apps-discuss@ietf.org to adopting this one as the common path forward. We would like to make a decision about which one to begin advancing in the next week or two.
>  
> Have a good weekend!
>  
> -MSK, APPSAWG co-chair
>  
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth