Subject: [webfinger] About "resource", host-wide info and jrd

From: Goix Laurent Walter <[email-masked]>
Date: Wed, 5 Dec 2012 11:01:42 +0100

Hi all,

I'd like to bring here the discussion on the mandatory usage of the "resource" parameter and the access to host-wide information.

I understand that webfinger now moved away from rfc6415, and the webfinger endpoint could be seen as a "lrdd" endpoint using "application/json" type.
However currently if a client would like to retrieve host-wide information there is no other option than using host-meta and/or host-meta.json.

This may be fine as long as webfinger and host-meta.json use the exact same data format (jrd) but anyway still require 2 endpoints being used with no clear meaning of whether to follow lrdd or go to the wf endpoint in case both are different.
Hence webfinger may need to support host-wide info on its own as well, for example by omitting the "resource" parameter. One could probably use the http root url of the domain itself as a valid resource parameter but http://example.com/.well-known/webfinger?resource=http://example.com seems quite a trick.

The omission of the "resource" parameter would also be useful in mobile networks where the app does not know the actual identity of the user (and may not be entitled to) but only the server does. In this case the server could answer anyway with some user-specific information and could include an acr: URI as an opaque identifier in the "subject" not to reveal the actual user identity.

I recognize that "resource" params MUST be supported by servers but usage in requests from client should remain unspecified so that they can decide whether to use it or not. In addition I would suggest that if a resource parameter is not provided, the server should answer with hostwide information unless it can retrieve the own user identity through other means, and in this case consider the request as resource-specific of the requesting user.

Otherwise what is the rationale for mandating the resource parameter in all queries?
walter

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.

Rispetta l'ambiente. Non stampare questa mail se non ? necessario.

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 6 Dec 2012 14:50:04 -0500

Walter,

I’ve not seen any comments on this, so let me ask question and make
comments.

What would be the expected response if the “resource” parameter was not
present?  You said:

The omission of the “resource” parameter would also be useful in mobile
networks where the app does not know the actual identity of the user (and
may not be entitled to) but only the server does. In this case the server
could answer anyway with some user

specific information and could include an acr: URI as an opaque identifier
in the “subject” not to reveal the actual user identity.

How would it help to return a document that is not user-specific?  If the
server provides replies for 1,000,000 users,  what user-specific information
would it return without an identifier?

We could certainly allow the server to return a default JRD of some sort if
no user-specific information is supplied, but it just takes in the direction
of RFC 6415.   So, if that’s the kind of solution you want, then I’d suggest
you do that.  Both RFC 6415 and WebFinger are related in that one was
derived from the other (albeit, significantly modified and simplified).
However, it seems reasonable to me that both can go forward.  And, it is
made simpler if both support a common format like JRD.

Paul

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Goix Laurent Walter
Sent: Wednesday, December 05, 2012 5:02 AM
To: [email-masked]; [email-masked]
Subject: [webfinger] About "resource", host-wide info and jrd

Hi all,

I’d like to bring here the discussion on the mandatory usage of the
“resource” parameter and the access to host-wide information.

I understand that webfinger now moved away from rfc6415, and the webfinger
endpoint could be seen as a “lrdd” endpoint using “application/json” type. 

However currently if a client would like to retrieve host-wide information
there is no other option than using host-meta and/or host-meta.json.

This may be fine as long as webfinger and host-meta.json use the exact same
data format (jrd) but anyway still require 2 endpoints being used with no
clear meaning of whether to follow lrdd or go to the wf endpoint in case
both are different. 

Hence webfinger may need to support host-wide info on its own as well, for
example by omitting the “resource” parameter. One could probably use the
http root url of the domain itself as a valid resource parameter but
http://example.com/.well-known/webfinger?resource=http://example.com seems
quite a trick.

The omission of the “resource” parameter would also be useful in mobile
networks where the app does not know the actual identity of the user (and
may not be entitled to) but only the server does. In this case the server
could answer anyway with some user-specific information and could include an
acr: URI as an opaque identifier in the “subject” not to reveal the actual
user identity.

I recognize that “resource” params MUST be supported by servers but usage in
requests from client should remain unspecified so that they can decide
whether to use it or not. In addition I would suggest that if a resource
parameter is not provided, the server should answer with hostwide
information unless it can retrieve the own user identity through other
means, and in this case consider the request as resource-specific of the
requesting user.

Otherwise what is the rationale for mandating the resource parameter in all
queries?

walter

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. 

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è
necessario.

---

From: Goix Laurent Walter <[email-masked]>
Date: Fri, 7 Dec 2012 01:35:59 +0100

Hello paul,

Thanks for this. My answers inline.

Le 6 déc. 2012 à 20:50, "Paul E. Jones" <[email-masked]<mailto:[email-masked]>> a écrit :

Walter,

I’ve not seen any comments on this, so let me ask question and make comments.

What would be the expected response if the “resource” parameter was not present?  You said:

The omission of the “resource” parameter would also be useful in mobile networks where the app does not know the actual identity of the user (and may not be entitled to) but only the server does. In this case the server could answer anyway with some user
specific information and could include an acr: URI as an opaque identifier in the “subject” not to reveal the actual user identity.

How would it help to return a document that is not user-specific?
It would greatly simplify the work of implementing+exposing both rfc6415 and webfinger if webfinger could also provide host wide info (which is potentially very easy to do if the resource param becomes optional). I am insisting on this because as it was remarked some month ago if webfinger goes a different direction from rfc6415 and you need to convince the current (open source) community of adopting webfinger, it has to do at least the same than what 6415 is currently doing, otherwise there are little chances for being adopted sooner.
useful Host-wide info can be for example the oauth2 endpoints or any other tel which URL may not vary on a user-specific basis.

If the server provides replies for 1,000,000 users,  what user-specific information would it return without an identifier?
In case the server manages to identify the target user anyway through other means (eg by recognizing the requesting user and implicitly consider it the target user as well), then it can return user-specific info. Putting or not the actual plain identifier in the subject may be an internal policy, and the use of acr: Uris (anonymous customer reference) to provide a hidden identity may be considered In other cases

We could certainly allow the server to return a default JRD of some sort if no user-specific information is supplied, but it just takes in the direction of RFC 6415.   So, if that’s the kind of solution you want, then I’d suggest you do that.  Both RFC 6415 and WebFinger are related in that one was derived from the other (albeit, significantly modified and simplified).  However, it seems reasonable to me that both can go forward.  And, it is made simpler if both support a common format like JRD.
Things would get much worse if both 6415 and wf would not share the same data format, especially if wf stays resource-specific only and does not accommodate host wide info

Walter

Paul

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Goix Laurent Walter
Sent: Wednesday, December 05, 2012 5:02 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [webfinger] About "resource", host-wide info and jrd

Hi all,

I’d like to bring here the discussion on the mandatory usage of the “resource” parameter and the access to host-wide information.

I understand that webfinger now moved away from rfc6415, and the webfinger endpoint could be seen as a “lrdd” endpoint using “application/json” type.
However currently if a client would like to retrieve host-wide information there is no other option than using host-meta and/or host-meta.json.

This may be fine as long as webfinger and host-meta.json use the exact same data format (jrd) but anyway still require 2 endpoints being used with no clear meaning of whether to follow lrdd or go to the wf endpoint in case both are different.
Hence webfinger may need to support host-wide info on its own as well, for example by omitting the “resource” parameter. One could probably use the http root url of the domain itself as a valid resource parameter but http://example.com/.well-known/webfinger?resource=http://example.com seems quite a trick.

The omission of the “resource” parameter would also be useful in mobile networks where the app does not know the actual identity of the user (and may not be entitled to) but only the server does. In this case the server could answer anyway with some user-specific information and could include an acr: URI as an opaque identifier in the “subject” not to reveal the actual user identity.

I recognize that “resource” params MUST be supported by servers but usage in requests from client should remain unspecified so that they can decide whether to use it or not. In addition I would suggest that if a resource parameter is not provided, the server should answer with hostwide information unless it can retrieve the own user identity through other means, and in this case consider the request as resource-specific of the requesting user.

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.
Rispetta l'ambiente. Non stampare questa mail se non è necessario.