Re: [apps-discuss] Webfinger

["Paul E. Jones" <[e-mail]>]

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:[e-mail]] 
Sent: Saturday, November 19, 2011 10:03 AM
To: Paul E. Jones; [e-mail]
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: [e-mail] [mailto:[e-mail]]
On Behalf Of Paul E. Jones
Sent: Monday, October 24, 2011 1:10 PM
To: [e-mail]
Cc: Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinger

 

Folks,

 

We just submitted this:

http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

 

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