[apps-discuss] R: Webfinger discussion

[Goix Laurent Walter <[e-mail]>]

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.