Re: [apps-discuss] Webfinger discussion

[Bob Wyman <[e-mail]>]

On Tue, Mar 27, 2012 at 2:18 PM, James M Snell <[e-mail]> wrote:

> 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...
>
Given WebFinger as currently defined, you are probably correct in saying
that the LRDD lookup is unnecessary. The reason for this is WebFinger only
defines a single variable for use in Templates. Thus, the easiest thing to
do is to simply define a standard URI for doing WebFinger lookups. The
Template mechanism provides more generality than is useful for WebFinger as
defined.

Things could have been different -- and I think that was part of folk's
original thinking here. For instance, WebFinger might have defined a few
more Template variables or provided for a registry of template variables.
In that case, we might have seen: "Full_Name", "telephone number,"
"Student_ID_Number" and many other variables Then, there would have been a
question as to how to construct the WebFinger query URI --  (Which
variables are supported by the current server?  How should the URI be
composed?).

It would, I think, simplify matters if, as you suggest, we define a fixed
URI for WebFinger. If anyone really wants a service that can be used to map
from attributes to WebFinger acct: URIs, then they can do so in a different
specification. (i.e. This new "WebFinger Acct Lookup Service" would do
lookups from stuff like "full_name"="bob wyman" to acct:[e-mail])

One other advantage that comes from using the two-step, template-driven
approach is that it is easier to handle re-directions in some environments.
Given the current spec, I can ask example.com/... for an LRDD that might
tell me that I really should be asking webfinger.example.com for WebFinger
information instead. Certainly, the same can be handled using HTTP
redirects, however, HTTP redirects may be managed by someone other than the
person who manages the LRDDs. (i.e. Given the way host-meta works, even if
I'm running a web site on a fairly strictly controlled shared service, I
can accomplish much by simply putting a file named ".well-known/host-meta"
on my site. But, it might be much harder for me to get those who run the
shared service to define a redirect for me.)

I like the idea of passing acct: URIs as hash values. Clearly, such simple
obfuscation is relatively transparent (subject to dictionary attack),
nonetheless, it would raise the cost of interception by a reasonably useful
amount. Nonetheless, I suspect that this is the sort of thing that might
best be a SHOULD for clients while a MUST for servers.

bob wyman


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