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

[Blaine Cook <[e-mail]>]

On 8 May 2012 16:55, Hannes Tschofenig <[e-mail]> wrote:
> 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.

Webfinger isn't about authentication. It is *explicitly* about
discovering information about an entity (usually a person) when you
(the relying party) *already have* their identifier.

Again: There is NO privacy leak in exposing the identifier to the RP,
because they already know it.

Again: There is NO privacy leak in exposing the identifier to the SP,
because they control it.

Even in the context of authentication, I'm surprised you're saying
this because I've repeatedly claimed that the *major failing* with
OpenID *.* is that the relying party isn't given knowledge of *who* is
trying to authenticate in the first place. It's a cryptographic
property that looks lovely on paper, but is a damaging folly when
translated to something that end users are expected to interact with.

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

Agreed, the actual information conveyed by Webfinger will normally be
private. *However*, as discussed on this list, on the OAuth list, and
in many other places, the mechanism(s) for authentication and
authorisation to access the relevant Webfinger profiles is best dealt
with by allowing any valid HTTP mechanisms.

Specific protocols that rely upon webfinger should define their own
authentication requirements, where sensible.

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

I have many concerns with this document, too, as mentioned earlier.

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

No-one is forcing all OAuth services to rely upon webfinger discovery.
OpenID Connect needs something like this, because users (and their RPs
in turn) need to know their identifier in order to be able to sign in.
Some RPs that interact with OAuth-enabled services (e.g., cloud
document services) will benefit from webfinger. Others won't,
especially where the RP shouldn't or can't know who the user is, but
should have access to a service.

FWIW, I think you're blowing the privacy concerns way out of
proportion, especially in the context of a world where many actively
hostile actors can identify users by analysing router traffic that
they obtain from back-doors in switches manufactured by Ericsson. ;-)

b.