Re: [apps-discuss] Webfinger discussion

James,

I really like this idea.  It makes an attempt to short-cut some of the procedures, very much in line with what the "resource" parameter does in Section 4.2 of the Webfinger draft.  I don't have a particular love for the using MD5, preferring something like this:

GET /.well-known/webfinger?resource=acct%3Abob%40example.com&rel=blog HTTP/1.1

Since any reply might have multiple links, then the 204 reply including links would likely be necessary.  Using 302 would not be right, since that has a different meaning: the client would go to Location trying to resolve the original request.  A 204 with any number of Link headers would be good.

Using the resource parameter means we make a query and get a JRD or XRD document.  What we cannot do is query for one specific type of content.

Changing Webfinger so drastically is a challenge since Webfinger builds on RFC 6415. But, I do like the idea of querying for a very specific value like this:

GET /.well-known/host-meta.json?resource=acct%3Abob%40example.com&rel=blog HTTP/1.1

Perhaps this might return a reply like this:

HTTP/1.1 204 No Content
Link: <http://blogs.example.org/bob/>; rel="blog"

A challenge with this, though, is that it means the application has to deal with two different formats.  Either JRD/XRD or an HTTP header with Links.

We could introduce this and make it mandatory if the resource parameter is supported.  However, would it make the client-side code simpler?  Support for the "resource" parameter is already optional.  (We could make it mandatory, but I did get pushback on that.)

Paul

> -----Original Message-----
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: Tuesday, March 27, 2012 2:19 PM
> To: Paul E. Jones
> Cc: Andrew Sullivan; apps-discuss@ietf.org
> Subject: 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 "bob@example.org", send a GET request to:
>   http://example.org/.well-known/finger/{md5(acct:bob@example.org)} 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 "bob@example.org" 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 <paulej@packetizer.com>
> 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:jasnell@gmail.com]
> >> Sent: Tuesday, March 27, 2012 12:39 PM
> >> To: Paul E. Jones
> >> Cc: Andrew Sullivan; apps-discuss@ietf.org
> >> 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
> >> <paulej@packetizer.com>
> >> 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: apps-discuss-bounces@ietf.org
> >> >> [mailto:apps-discuss-bounces@ietf.org]
> >> >> On Behalf Of Andrew Sullivan
> >> >> Sent: Tuesday, March 27, 2012 4:47 AM
> >> >> To: apps-discuss@ietf.org
> >> >> 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
> >> >> ajs@anvilwalrusden.com
> >> >> _______________________________________________
> >> >> apps-discuss mailing list
> >> >> apps-discuss@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/apps-discuss
> >> >
> >> > _______________________________________________
> >> > apps-discuss mailing list
> >> > apps-discuss@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >