Re: [apps-discuss] R: Webfinger discussion

[Bob Wyman <[e-mail]>]

On Wed, Mar 28, 2012 at 11:17 AM, Goix Laurent Walter <
[e-mail]> wrote:

> > i have not seen webfinger usages where “values” are directly provided
What is a "pointer" for you may be a "value" for me. Consider the case
where the URL of my blog is identified. Is that a pointer, a value or both
at the same time? It seems to me that in these cases, the distinction
between "pointer" and "value" is not inherent to the data provided but
rather is found in how the data is used.

bob wyman

On Wed, Mar 28, 2012 at 11:17 AM, Goix Laurent Walter <
[e-mail]> wrote:

>  On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter <
> [e-mail]> wrote:
> > more a protocol for accessing user info rather than discovery
> Forgive me if I'm being dense, but could you expand a bit on the
> difference between "accessing user info" and "discovery?"****
>
> ** **
>
> [walter] by "accessing user info” I mean directly accessing actual
> information about a user (my profile details, activity stream, etc). what I
> mean by “discovery” is to retrieve a pointer to a specific information.
> Webfinger is aimed at becoming a discovery protocol. There are plenty of
> other protocol/apis/interfaces for accessing information that could be
> “discovered” through webfinger and then use very different/specific
> communications means. I hope I clarified my point here.****
>
> ** **
>
> > - regarding OAuth it can be valuable in case webfinger is queried
> directly by applications.****
>
> Certainly, OAuth would be useful when combined with WebFinger. I would
> like to be able to have the equivalent of ACLs that would be used to vary
> the WebFinger responses based on who authenticates. For instance, in
> mapping from acct: URI to mailto:, I might want one group of people to
> receive one mailto: and another group to see a different value or no
> value.****
>
> ** **
>
> I think we need to also consider that there are alternatives to existing
> practice of providing "values" directly in the WebFinger XRD/JRDs. An
> alternative would be to provide  pointers to other services that can
> provide the desired answers. (i.e. Adding yet another level of
> indirection...) in other words, rather than providing the mailto: address
> that corresponds to a particular acct: URI, the XRD/JRD could point to a
> service which uses OAuth and that can be queried to provide whichever of
> several mailto: addresses that are appropriate -- depending on the
> results of authentication.****
>
> ** **
>
> [walter] i have not seen webfinger usages where “values” are directly
> provided and would be very careful with it (I would be glad to see if there
> are already such usages deployed). Imho the entire purpose of webfinger is
> to discover “pointers” to information, not the information itself. This
> allows any security mechanism to be applied on those specific endpoints (+
> on webfinger endpoint itself) to control access to the actual information
> (profile, activities, etc). ****
>
> Again, oauth could work for users/invocations within a single social
> network/domain, but I could hardly imagine it working for server-to-server
> transactions (eg a user from one SN acts on his server’s webpage to follow
> a user on another SN). Or do you have other scenarios in mind with oauth?*
> ***
>
> The only direct information I could easily imagine in a xrd is another
> “acct” uri in case of portability. Other personal uris (eg im:, mailto:,
> etc) should be handled with care and imo not included in the xrd but rather
> in a profile description (hcard, foaf, etc), whose link is provided in the
> xrd (so that a more precise acl can be applied when someone wants to access
> it)****
>
> ** **
>
> walter****
>
> ** **
>
> bob wyman****
>
> On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter <
> [e-mail]> wrote:****
>
> Hello james, all,
>
> I could see many sort of threads going in parallel in this discussion
> addressing different types of concerns. I don't want to enter the
> "security" discussion here but rather comment on some specific technical
> points related to the "protocol":
>
> - the "finger" (or lrdd) well-known endpoint could be a shortcut to
> consider to directly invoke the webfinger endpoint without the need for the
> host-meta. This skips one http transaction, although I would imagine in
> most cases that the host-meta xrd 1) can be cached by the invoking client,
> 2) can contain additional useful info (eg OExchange endpoint link).
>
> - I am not sure about the exact value brought by the md5 hash, also
> considering that APIs already exist (e.g. OpenSocial) that use plain
> identifiers as part of the path. I cannot see much difference here wrt
> security that justifies this need for webfinger. In any case support for
> md5 hash would probably need to be declared by the server, eg using
> {md5uri} instead of {uri} in the lrdd template.
>
> - regarding the shortcuts to link rel types this is becoming more a
> protocol for accessing user info rather than discovery. i can see this as a
> direct/standard API/URL to access user information (e.g. avatar,
> profile-page). This misses the "type" (content-type) which may vary within
> a single rel (although this could be addressed by Accept: headers) and is
> significantly different from the original scope of webfinger for discovery
> only (I could imagine you could further extend your proposal to perform
> CRUD operations on the single rels, which tends to become close to
> opensocial apis).
> The information contained in the xrd/jrd can in fact easily be cached
> altogether for subsequent use and not for immediate consumption of all rel
> types. I would assume this is not more complex than parsing the various
> Link: headers in the responses.
> But i can understand there may be some new use case where a user is only
> interested in 1-2 rels for instant consumption, and some solution may be
> investigated for this.
>
> - regarding OAuth it can be valuable in case webfinger is queried directly
> by applications. However in most current usages (ostatus, diaspora, etc)
> the webfinger discovery process is performed by a server of another domain,
> thus limiting the possible usage of oauth in that case.
>
> walter
>
> -----Messaggio originale-----
> Da: [e-mail] [mailto:[e-mail]]
> Per conto di James M Snell
> Inviato: martedì 27 marzo 2012 20.19****
>
> A: Paul E. Jones
> Cc: [e-mail]****
>
> Oggetto: Re: [apps-discuss] Webfinger discussion****
>
>
> They are rather technical in nature and speak to the overall operation
> of the protocol. I've written up a detailed version of my feedback
> here [1]
>
> [1] http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html
>
> The summary version is this: I believe we can make this even simpler
> without sacrificing basic operation by saying simply:
>
>  If I want to know about user "[e-mail]", send a GET request to:
>  http://example.org/.well-known/finger/{md5(acct:[e-mail])} and
>  see what I get back.
>
> The requirement to use XRD/JRD and first look up information about the
> LRDD service in host-meta is quite unnecessary. Also note that the ID
> is hashed in the request URI for privacy/security purposes...
>
> We can expand on that basic idea further to say:
>
>  If I want to know if "[e-mail]" has a "blog" and where it is
> located,
>  I could simply send a request to:
>
> http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog
>
>  and the server can respond with a redirect to the proper location:
>
>  HTTP/1.1 302 Found
>  Location: http://blogs.example.org/bob
>
> The "/blog" portion of the request URI specifies a Link rel... if I
> want to discover some other type of service... say, the users profile
> or avatar, I simply link the different rel attribute value there..
> e.g.
>
>
> http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/avatar
>
> http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/profile
>
> If there are multiple links for a particular rel, the server can
> respond with a 300 Multiple Options response.
>
> The point is that requiring XRD/JRD isn't actually necessary, and
> requiring the initial host metadata step isn't required also.
>
> Requiring CORS is also isn't necessary.
>
> Anyway, that's the basic rundown.
>
> - James
>
> On Tue, Mar 27, 2012 at 9:57 AM, Paul E. Jones <[e-mail]>
> wrote:
> > James,
> >
> > If the other items are editorial, perhaps just direct them to me.  If
> they are items that others might want to weigh in on, then this list is the
> appropriate venue.
> >
> > Paul
> >
> >> -----Original Message-----
> >> From: James M Snell [mailto:[e-mail]]
> >> Sent: Tuesday, March 27, 2012 12:39 PM
> >> To: Paul E. Jones
> >> Cc: Andrew Sullivan; [e-mail]
> >> Subject: Re: [apps-discuss] Webfinger discussion
> >>
> >> To be fair, there are ways of dealing with the potential for security
> >> leaks of this nature with WebFinger that did not really exist with the
> >> original Finger protocol. OAuth 2, for instance. A WebFinger endpoint
> >> could choose to serve up only the most basic static information to
> >> unauthenticated requesters, but then provide a means for a requester to
> >> authenticate and request permission from the target user or provider to
> >> acquire additional information as part of the response.
> >>
> >> On a side note to Paul: I did have some additional general comments on
> the
> >> WebFinger spec itself, I wanted to ask where such comments would be best
> >> directed for discussion.
> >>
> >> - James
> >>
> >> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones <[e-mail]>
> >> wrote:
> >> > I agree it would be useful to add text about sharing information that
> >> > might be dynamic in nature (e.g., current user location).
> >> >
> >> > We'll add text along those lines to the next draft.  Any other
> >> > security considerations we should note?
> >> >
> >> > Paul
> >> >
> >> >> -----Original Message-----
> >> >> From: [e-mail]
> >> >> [mailto:[e-mail]]
> >> >> On Behalf Of Andrew Sullivan
> >> >> Sent: Tuesday, March 27, 2012 4:47 AM
> >> >> To: [e-mail]
> >> >> Subject: Re: [apps-discuss] Webfinger discussion
> >> >>
> >> >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote:
> >> >>
> >> >> > un-recommended!). If people did, in fact, use WebFinger to record
> >> >> > such stuff, the concerns you mentioned would be relevant. Thus, it
> >> >> > might make sense for the Security Considerations section to suggest
> >> >> > that one should think carefully before using WebFinger to provide
> >> >> > such dynamic
> >> >> information.
> >> >>
> >> >> Right, that's most of what I was trying to say.  I do have a concern
> >> >> that collecting a bunch of different information about a given person
> >> >> and linking it together in a single, easy to access repository has
> >> >> some potential security side effects (not just privacy ones, but
> >> >> those too, of
> >> >> course) that are not clearly highlighted in the security
> >> considerations.
> >> >> I suppose one could argue that facebook's (or pick your poison) user
> >> >> population shows nobody cares about that, but I think it would still
> >> >> be good to have some observations about those effects.
> >> >>
> >> >> Best,
> >> >>
> >> >> A
> >> >>
> >> >> --
> >> >> Andrew Sullivan
> >> >> [e-mail]
> >> >> _______________________________________________
> >> >> apps-discuss mailing list
> >> >> [e-mail]
> >> >> https://www.ietf.org/mailman/listinfo/apps-discuss
> >> >
> >> > _______________________________________________
> >> > apps-discuss mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >
> _______________________________________________
> 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.****
>
>
> _______________________________________________
> 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.*
> *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa
> mail se non è necessario.*
>
>