On 8 May 2012 16:55, Hannes Tschofenig <hannes.tschofe...@gmx.net> 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. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
