Re: [apps-discuss] Webfinger discussion

[Eran Hammer <[e-mail]>]

RFC 6415 (host-meta) was the end of a long evolution of discovery ideas. I would strongly caution against throwing it away and starting from scratch given the amount of experience and balance that was put into it. There are easy things we can do to make it easier to use and more efficient, without losing its main architectural benefits (caching, simplicity, ease of deployment, efficiency in templates, security, flexible schema, etc.).

In the past I've proposed adding query parameters to the endpoint to allow for direct retrieval of information without having to parse the document. I have also suggested moving away from XRD to JRD as the primary format. BTW, XRD has nothing to do with XRI and all to do with HTTP Link relations - so people should get over their bias and hate for XRI and give this work the benefit of the doubt.

The key to this work has always been adoption. These protocols are useless without large companies (primarily email providers as currently proposed) supporting it, which was a significant driving force in shaping the protocol based on what these companies were able and willing to deploy.

For example, Yahoo was a strong supporter of the template mechanism because it enable them to deploy a single static file that provided information about all their users for the purpose of address book discovery.

EH


> -----Original Message-----
> From: [e-mail] [mailto:apps-discuss-
> [e-mail]] On Behalf Of Paul E. Jones
> Sent: Wednesday, March 28, 2012 2:50 PM
> To: 'James M Snell'
> Cc: [e-mail]
> Subject: 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:[e-mail]]
> > Sent: Tuesday, March 27, 2012 2:19 PM
> > To: Paul E. Jones
> > Cc: Andrew Sullivan; [e-mail]
> > 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 "[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