Re: [apps-discuss] R: Webfinger discussion

[Bob Wyman <[e-mail]>]

On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter <
[e-mail]> wrote:
> more a protocol for accessing user info rather than discovery
Forgive me if I'm being dense, but could you expand a bit on the difference
between "accessing user info" and "discovery?"

> - regarding OAuth it can be valuable in case webfinger is queried
directly by applications.
Certainly, OAuth would be useful when combined with WebFinger. I would like
to be able to have the equivalent of ACLs that would be used to vary the
WebFinger responses based on who authenticates. For instance, in mapping
from acct: URI to mailto:, I might want one group of people to receive one
mailto: and another group to see a different value or no value.

I think we need to also consider that there are alternatives to existing
practice of providing "values" directly in the WebFinger XRD/JRDs. An
alternative would be to provide  pointers to other services that can
provide the desired answers. (i.e. Adding yet another level of
indirection...) in other words, rather than providing the mailto: address
that corresponds to a particular acct: URI, the XRD/JRD could point to a
service which uses OAuth and that can be queried to provide whichever of
several mailto: addresses that are appropriate -- depending on the results
of authentication.

bob wyman

On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter <
[e-mail]> wrote:

> 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.
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>