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

[Goix Laurent Walter <[e-mail]>]

Hello hannes, all,
[snip]
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.

[walter] for host-wide information you may query for /.well-known/webfinger?resource=http://example.com although it looks quite odd to me (but technically feasible) and certainly isn’t called out in the current text to know. Or you could (better) rely on the host-meta endpoint (rfc6415) and use xrd or jrd representation, optionally over https if you care about security. This is the approach we took within OMA to autoconfigure the client based on the pure domain information (the rp does not necessarily have the knowledge of the username and shouldn’t ask the user for it). This way you can discover the oauth2 endpoints for example and get the user login on his favorite portal to obtain his token.


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/

IESG discussion can be tracked via
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

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

[cid:[e-mail]]Rispetta l'ambiente. Non stampare questa mail se non è necessario.