Subject: Re: [apps-discuss] Webfinger

From: "Mykyta Yevstifeyev (М. Євстіфеєв)" <[email-masked]>
Date: Sat, 03 Dec 2011 07:38:48 +0200

Bjoern,

The "Author's Addresses" section is not ironic but just an unfilled 
template in XML source, I guess.  Moreover, Webfinger as well as 
original finger are supposed to be means of retrieving information which 
is publicly available, and this is decided by the owner of such 
information.  "If you don't like it, don't use it" principle is very 
relevant here, and I don't see reasons to argue.

Mykyta Yevstifeyev

24.11.2011 5:34, Bjoern Hoehrmann wrote:
> * Paul E. Jones wrote:
>> http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt
> There:
>
>     Suppose you meet somebody at a party and they provide you with their
>     email address.  After the party, you decide to visit your new
>     friend's blog to learn more about them.  How do you find it?  You
>     could search for your friend's name on the Internet or on various
>     social networking sites, but sometimes it is very hard to locate a
>     person or information about a person with merely an email address or
>     a name.
>
> I believe the technical term for that is "cyberstalking". What are you
> planning to do to ensure the draft properly addresses security, privacy,
> and netiquette issues? Right now the document seems to omit the reasons
> for why the finger protocol did not gain traction, which revolve around
> privacy and social engineering security issues, does not discuss neti-
> quette at all, just has a "if you don't like it, don't use it" remark
> in the Security Considerations, and has an ironic "Author's Addresses"
> section.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 16 Dec 2011 09:34:37 -0500

Walter,

Sorry for the very belated reply.  I’ve been busy :)

If we immediately jump to an lrdd resource, then we will miss content that
would have been provided by host-meta.  Erin wanted the “resource” parameter
passed to host-meta so that we get all of the rels there and those provided
by lrdd.  That’s an interesting optimization, though it concerns me that we
have to means of accessing the same information.  Two HTTP queries is
certainly less optimal, but then again, most queries to any web site results
in many queries that could be optimized.  Why not just return everything
needed to populate a page when performing a “GET /”? :)  Can we guarantee
that all web servers would implement the optimization?  If they don’t, we
still have to issue two queries.  Personally, I prefer issuing two queries
than having conditional statements in the code to accommodate different
behavior.  If we introduce the optimization, I’d prefer that it be
mandatorily supported.

I like yours idea of asking for specific rels if the client knows what it’s
after.  However, two parameters with the same name is a no-no.  So this
syntax:

   resource=acct:[email-masked]&rel=hub&rel=author

should be different.  For example, we could introduce this syntax:

   resource=acct:[email-masked]&rels=hub,author

This serves to reduce the client-side processing, but increases the
server-side processing.  If we expected a Webfinger query to return volumes
of information, I could see value in reducing the information returned (as a
benefit to both the client and server).  However, I don’t expect that to be
the case for Webfinger.  I believe distributing the work between the client
and server is reasonable and I’d suggest that we not have the server parse
the list of rels in an effort to offload a bit of client-side processing.
For the client, I think the extra work is minimal.  For the server, it’s a
minimal amount of sifting multiplied by the number of queries per second it
will receive.

Paul

From: Goix Laurent Walter [mailto:[email-masked]] 
Sent: Wednesday, November 23, 2011 3:45 AM
To: Eran Hammer-Lahav; Paul E. Jones; [email-masked]
Cc: 'Joseph Smarr'
Subject: R: [apps-discuss] Webfinger

All,

I am not sure that making the host-meta itself act as a proxy for
resource-specific information is the best option.

There are probably different use cases we are thinking of:

- one is related to a server that wishes to interact with (multiple) users
on another server.

- another (more unclear to me) is related to a web app directly requesting
specific information about a remote user

For the first scenario the local server would probably retrieve the remote
host-meta once, cache it and then perform queries for each user using the
lrdd link template. Also typically this large amount of users may not be
known simultaneously, so no need for specifying a list of users (resources)
in the same query. However I would assume in most cases the urls/templates
for the target rels in the single resource descriptor provided by the remote
server may often be along the same pattern. This may call for an easier
mechanism for a server to discover/cache not only the lrdd template but the
other rels it needs (avatar, profile-page, etc): I can understand this may
not always be feasible but at least it would save numerous queries.

In the second one the web app typically would ideally like a single request
(json) to get a specific info (1 or more rels) about a specific user
(resource). This calls for some sort of standard API but I'm not sure it is
host-meta responsibility to define it. In principle this would be like
standardizing the lrdd endpoint and its parameters ('rel' and
'resource/uri').

Summarizing, what about rethinking the following:

1- standardize (under webfinger) the lrdd endpoint (e.g as
“.well-known/lrdd[.json]”) so that we can save one invocation from a web app

2- enable/suggest this same lrdd endpoint to provide back rels as templates
when no specific resource is requested. This may require the definition of
additional variables ({}) to refer to the username only for example (in
general to give more flexibility to the hosting server), whilst at the same
time potentially enabling the requesting server to cache these templates and
use them to retrieve user information more easily/frequently 

Probably in both cases the entity performing the invocation knows already
which rels is needs, so filters here may be useful although not a must.

Here are some examples:

Ø  GET
/.well-known/lrdd.json?resource=acct:[email-masked]&rel=hub&rel=author
HTTP/1.1

   {

      "subject":"acct:[email-masked]",

      "links":[

        {

          "rel":"hub",

          "href":"http://example.com/xy/hub",

        },

        {

          "rel":"author",

          "href":"http://example.com/xy",

        },

        {

          "rel":"author",

          "template":"http://example.com/author?q=acct:xy%40example.com"

        }

      ]

    }

Ø  GET /.well-known/lrdd?rel=hub&rel=author HTTP/1.1

<?xml version="1.0" encoding="UTF-8"?>

     <XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0">

       <Subject>example.com</Subject> <!-- host name here -->

       <Link rel="hub"

             template="http://example.com/{username}/hub
<http://example.com/%7busername%7d/hub> "/> <!-- {username} could be defined
to refer to that part only of the URI. Works with acct: URI only… -->

       <Link rel="author" template="http://example.com/{username}
<http://example.com/%7busername%7d> "/>

       <Link rel="author" template="http://example.com/author?q={uri}
<http://example.com/author?q=%7buri%7d> "/>

     </XRD>

Thoughts?

walter

Da: Eran Hammer-Lahav [mailto:[email-masked]] 
Inviato: martedì 22 novembre 2011 20.10
A: Paul E. Jones; Goix Laurent Walter; [email-masked]
Cc: 'Joseph Smarr'
Oggetto: RE: [apps-discuss] Webfinger

Not exactly. Resource gives all the links for that resource. Rel further
reduces the selection. If you need 10, don’t use rel, just resource.

EHL

From: Paul E. Jones [mailto:[email-masked]] 
Sent: Tuesday, November 22, 2011 10:55 AM
To: 'Goix Laurent Walter'; Eran Hammer-Lahav; [email-masked]
Cc: 'Joseph Smarr'
Subject: RE: [apps-discuss] Webfinger

Walter,

Including the ‘resource’ parameter could remove the need to further process
the templates on the client side and to perform a second query for the
“lrdd” XRD/JRD document.  If the server implementation does not support the
“resource” parameter, then the client would have to go about it as it would
today.

I like the idea of reducing complexity on the client, but if resource is
optional, then we do not actually reduce the complexity at all.  It does
potentially reduce the time required to fetch the information by one
round-trip to the server.  Is that worth it?  Perhaps.  For most data, there
are three queries:

1)      host-meta

2)      LRDD

3)      Actual data sought (e.g., an avatar file)

Introducing “resource” means we do to queries:

1)      host-mesa?resource

2)      Actual data sought (e.g., an avatar file)

That sounds good for a single piece of information.  However, if the client
needs to perform 10 queries for 10 links found, then that one additional
step is little savings.  I’m on the fence over it.

Paul

From: Goix Laurent Walter [mailto:[email-masked]] 
Sent: Tuesday, November 22, 2011 1:42 PM
To: Eran Hammer-Lahav; Paul E. Jones; [email-masked]
Cc: 'Joseph Smarr'
Subject: R: [apps-discuss] Webfinger

I guess the discussion is moving from a pure descriptor (which may be static
in most cases) to a sort of API, which could have endless parameters.

>From the current/original webfinger description, the host-meta would mostly
be static, which implies no API-like, and no parameter, but the lrdd link
can typically be dynamic/API-like (to support the template mechanism). As
such it could easily accommodate some more parameters as well (in a similar
flavor than opensearch), e.g. to request specific link rels if we want.

What would be the scope of supporting uri parameters when accessing
host-meta? Does this intend to save an interaction step?

walter

Da: [email-masked] [mailto:[email-masked]] Per
conto di Eran Hammer-Lahav
Inviato: martedì 22 novembre 2011 19.33
A: Paul E. Jones; [email-masked]
Cc: 'Joseph Smarr'
Oggetto: Re: [apps-discuss] Webfinger

Yes, it is no longer a template and must be converted to href.

As for testing support, just check for Subject. Pretty simple to do.

EHL

From: Paul E. Jones [mailto:[email-masked]] 
Sent: Tuesday, November 22, 2011 9:27 AM
To: Eran Hammer-Lahav; [email-masked]
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

A couple more questions on (3):

Why expand templates like this:

        {

          "rel":"author",

"template":"http://example.com/author?q=http%3A%2F%2Fexample.com%2Fxy"

        }

The requesting entity could expand the templates.  I can appreciate the
reasoning for having “?resource” query the LRDD URL and return back the
ordered list of links, but why have the server modify the discovered
templates like the one above?  It’s no longer a template, really.  Should we
change “template” to be “href”?

If a server does not understand “?resource”, it’s likely to simply ignore
it.  But, if a client expects it to be processed, it will cause confusion.
Would it be better to introduce /.well-known/host-meta-resource?  If a 404
is returned, then that is a clear indicator to the client.  Other
suggestions?

Paul

From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Monday, November 21, 2011 9:52 PM
To: Paul E. Jones; [email-masked]
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

1.       Require the server to offer JRD, leave it to the client to pick one
flavor.

2.       Host-meta dumps the decision on the applications. You need to
decide if WebFinger is an application or just syntactic sugar on top of
host-meta.

3.       Expand every template in host-meta + level one LRDD links
(excluding templates in LRDD).

EHL

From: Paul E. Jones [mailto:[email-masked]] 
Sent: Monday, November 21, 2011 7:49 AM
To: Eran Hammer-Lahav; [email-masked]
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

Eran,

Thanks for your feedback.  The editorial, structural, and behavioral items
we’ll addressed (including adhering to host-meta section 4.2).

Let me ask about specific comments:

1)      You want to mandate use of JSON, which we also indicated in the
draft.  However, I would personally prefer to give both XML and JSON equal
weight and require both.

2)      You wanted to mandate HTTPS. I’m not opposed, but host-meta does not
mandate it.  Shouldn’t we Webfinger requirements on what is there?

3)      Regarding “resource” extension: if I query host-meta, there may be
any number of templates.  Would we want the server to automatically expand
every template it finds?  Or would we only expand the ‘lrdd’ template?  (And
how many levels of recursion might be possible?)

Paul

From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Saturday, November 19, 2011 10:03 AM
To: Paul E. Jones; [email-masked]
Cc: Joseph Smarr; Gonzalo Salgueiro; Blaine Cook
Subject: RE: [apps-discuss] Webfinger

This is a good start. Some feedback and nits:

1.       The protocol flow is incorrect and needs to be adjusted based on
the final host-meta specification (RFC 6415). Namely, WebFinger must follow
section 4.2 exactly as specified.

2.       WebFinger should focus exclusively on JSON and mandate WebFinger
providers to support the JRD format. This does not preclude using XRD (XML)
but it will ensure that every compliant WebFinger implementation provides
full JSON support which is much more likely to be adopted. This is something
we could not do in host-meta due to the late stage it was in, but this is
the right time to make the switch (without taking away any existing
functionality).

3.       Are there reasons not to mandate HTTPS?

4.       Section 3 should be a sub-section of the introduction and each
example needs actual JRD code.

In addition, I would very much like to see WebFinger extend the host-meta
endpoint by defining a ‘resource’ query parameter. Using the example in RFC
6415 section 1.1.1 (example not properly encoded to make it easier to read):

> GET /.well-known/host-meta?resource=http://example.com/xy HTTP/1.1

   {

      "subject":"http://example.com/xy",

      "properties":{

        "http://spec.example.net/color":"red"

      },

      "links":[

        {

          "rel":"hub",

          "href":"http://example.com/hub",

        },

        {

          "rel":"hub",

          "href":"http://example.com/another/hub",

        },

        {

          "rel":"author",

          "href":"http://example.com/john",

        },

        {

          "rel":"author",

"template":"http://example.com/author?q=http%3A%2F%2Fexample.com%2Fxy"

        }

      ]

    }

The rules for this extension parameter are pretty simple:

1.       JSON is implied. If the server understands ‘?resource’ it MUST
return a JRD document.

2.       The subject must be set to the value of the ‘resource’ parameter.

3.       If the server does not support that resource (wrong domain, etc.)
it must return an empty JRD with the right subject.

4.       The client MUST verify the server supports ‘?resource’ by making
sure the response is both JRD and has the requested subject (this will
ensure full compatibility with any other host-meta endpoint).

I would like to see such endpoint extension required for WebFinger so that
clients can make a single call and get the full WebFinger result in JSON.
This would significantly improve adoption and usability, and adds very
little work to providers.

EHL

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Paul E. Jones
Sent: Monday, October 24, 2011 1:10 PM
To: [email-masked]
Cc: Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinger

Folks,

We just submitted this:

The tools for Webfinger are now defined, but the procedures need to be
clearer with respect to what most of us understand as “webfinger”.  This is
just a first stab at making that happen and we hope to progress this to
publish an RFC in the application area.

We welcome any comments you have on the topic, either privately or publicly.

Paul

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. 

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è
necessario. 

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. 

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è
necessario.