Re: [apps-discuss] Last Call: <draft-ietf-appsawg-webfinger-10.txt> (WebFinger) to Proposed Standard

["Hannes Tschofenig" <[e-mail]>]

Hi all,

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

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.

For example, in Section 3.1 the example talks about a user receiving an email from [e-mail] 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.

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.

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.

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?

Then, there is a question about the lack of privacy considerations in the document.

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

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.

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 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 would even volunteer to provide text but I fear that you are not going to like it.

Ciao
Hannes

Gesendet: Montag, 04. März 2013 um 21:24 Uhr
Von: "The IESG" <[e-mail]>
An: IANA <[e-mail]>
Cc: [e-mail]
Betreff: [apps-discuss] Last Call: <draft-ietf-appsawg-webfinger-10.txt> (WebFinger) to Proposed Standard

The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'WebFinger'
<draft-ietf-appsawg-webfinger-10.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[e-mail] mailing lists by 2013-03-18. Exceptionally, comments may be
sent to [e-mail] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


This specification defines the WebFinger protocol, which can be used
to discover information about people or other entities on the
Internet using standard HTTP methods. WebFinger discovers
information for a URI that might not be usable as a locator
otherwise, such as account or email URIs.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/" target="_blank" rel="nofollow">http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/" target="_blank" rel="nofollow">http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/


No IPR declarations have been submitted directly on this I-D.


_______________________________________________
apps-discuss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/apps-discuss" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/apps-discuss