Hannes, > I was hoping that some of the remarks that I provided last year (e.g., > http://www.ietf.org/mail-archive/web/oauth/current/msg08965.html) would > help to clarify the content of the document. That didn't quite happen...
Yeah, I wasn't copied. > In earlier versions of the document I had the impression that the acct: > URI scheme always had to be used as input to the lookup process but as > Section 4.5 explains this is not necessary. The resource parameter may > contain other URIs as well. Section 4.5 does not give a lot of > description of when certain URIs are utilized. Correct, any URI might be used. That does not mean that the server will respond for every URI, but some wanted "acct" and "email" and "tel" URIs, for example. Also, using an HTTP URI could be used to return additional information about a URI. > For example, in Section 3.1 the example talks about a user receiving an > email from b...@examle.com and this email address is then used by > WebFinger but the request example shows an acct: URI scheme (rather than > a mailto URI). It seems that there is the unstated assumption (at least > in that example) that the mailto URI is the same as the acct: URI, which > of course isn't necessarily the case. I believe it would be good to > state these assumptions to avoid confusing the reader. Fair point. How about immediately following the example, we add: 'Note the assumption made in above example that there is an "acct" URI for the given "mailto" URI. This is not always the case.' > Think about it: If you receive a SIP URI (which also has an email alike > structure with a username @ domain part) that does not mean either that > you can use this as an email address either. In some rare cases you > might. That's definitely true. However, this is one reason for encouraging the use of the "acct" URI scheme, though. In general (though not always), there is account associated with the user. The SIP URI, mailto URI, etc., each have a user part. I believe it is a reasonable assumption that there *may be* an 'acct' URI for the user. If not, WF will return nothing. We intended WF to be useful to humans, too, which means that if a user sees pau...@packetizer.com, the user will assume that might be a means of reaching "paulej" at "packetizer.com" using any number of tools (email, XMPP, H.323, etc.). They would be correct for most. Thus, there is encouragement for WF servers to use the acct URI. > If you believe that everyone would get the difference anyway (because > the URI scheme determines the semantic of the identifier) then have a > look at the Google WebFinger page (see > http://code.google.com/p/webfinger/). At least these guys don't > understand the difference either. There was even a proposal that we use no URI scheme at all and merely have the user@domain identifier. However, there is value in using a proper URI with WF, since querying "h323:pau...@packetizer.com" might return the address of my Gatekeeper, for example, versus the information that would be returned for my account. > In general, I am wondering whether there are additional assumptions > implied about the URI scheme associated with the identifier in the > lookup mechanism. For example, the text in Section 3.3 talks about email > client configuration and it seems that the requestor is interested in > receiving information about the email configuration based on the > resource=mailto... URI scheme usage. If I use a different URI scheme > (like a aaa: URI scheme) would my response look different? Yeah, it might look different. What a WF server wishes to return for a given URI is really up to the administrator. It might be that the same information is returned for any given URI scheme having the same user@domain part, but the server could return different responses. > Then, there is a question about the lack of privacy considerations in > the document. We do have quite a bit of text in the security considerations section. This will be called out more clearly with sub-sections, but there are at least three full paragraphs on privacy, even going to the point of providing the example that sharing location information might put a person in danger from someone who wishes to inflict harm on them. Personally, I thought that went a bit overboard, but that text was requested, so it's there. > The usage of the WebFinger mechanism requires the requestor to have > access to the full username@domain identifier. While this may be OK in > some cases when the response relates very much to the specific user > account it may be a problem in other cases. For example, in the OAuth > case there is the idea that the user identifier may be hidden from the > relying party but you have just required that identifier to be provided > to the relying party to start the entire OAuth exchange (in the > discovery). WF is not for use with every protocol, so I cannot address OAuth generically. However, WF *is* used as a part of OpenID Connect. So, yes, the user provides his/her identifier to the RP. However, that decision is a matter outside the scope of WF. > The example in Section 3.1 returns information that relates to the > specific username and therefore it makes sense to provide the username > part of the identifier to the service that constructs the query. For the > OpenID Connect discovery procedure described in Section 3.2 I wonder > whether this is always desirable. This was requested as an example to align with the OpenID Connect specs. > Could you expand the description a bit to explain why the relying party > in this case has to obtain the username part as well? The returned > information does not seem to be specific to a certain user. It is the > server configuration. It would be nice if the configuration of an > identity provider software (e.g., OpenID Connect) is not different for > every user. I'm not sure what to add, but I would welcome input. My understanding is that this is how OpenID Connect works. If I were to visit a web site and log in, what do I provide the site? It would not necessarily have to be my email address. It could be user123...@openid-connect-provider.net Whatever the case, something has to be provided. A simple user@domain identifier is something most users understand. The URIs used with OpenID were not so friendly for the average user. > I believe it is just fair to ask for a warning to be added to the > security consideration section indicating that WebFinger may have an > impact on your privacy expectation since it shares information with the > relying party that other mechanisms do not provide. So, if you think > that this just works like other discovery mechanisms the IETF had worked > on in the past then you might be surprised. I'm OK with introducing more text to the security considerations section, but it should not be heavily focused on OpenID or OpenID Connect. Many readers of this spec would not even know what a "relying party" is, ether. We should keep it generic. > I would even volunteer to provide text but I fear that you are not going > to like it. :-) Well, I didn't like some of the other text that was added, but I accepted it since people demanded it. If there is another broad point that needs to be made, then I'm willing to add the text. I just added a section on "abuse potential", as you might have seen. Paul
