Re: [apps-discuss] Webfinger discussion

[James M Snell <[e-mail]>]

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
>