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 bob(_at_)examle(_dot_)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
paulej(_at_)packetizer(_dot_)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:paulej(_at_)packetizer(_dot_)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 user123456(_at_)openid-connect-provider(_dot_)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