RE: Webfinger & FedSocWeb notes from IIW

Evan,

 

Comments in green:

 

 

 

From: Evan Prodromou [mailto:evan@status.net] 
Sent: Wednesday, October 31, 2012 2:21 PM
To: Paul E. Jones
Cc: webfinger@googlegroups.com; public-fedsocweb@w3.org
Subject: Re: Webfinger & FedSocWeb notes from IIW

 

On 12-10-30 09:21 PM, Paul E. Jones wrote:

Markus, thanks for sharing.  I copied Evan since there were some points on
the page that I thought were worth discussing.

 

"Webfinger has JSON now, but didn't have it when SWD was invented."

That's not quite right.  JSON has been a part of WebFinger since RFC 6415.
The only issue was that JSON was not mandatory on servers.  That said,
anyone wishing to allow use of OpenID Connect on their domain could have
implemented JSON support if the spec demanded it.  It's not an issue now,
anyway, since JSON is now mandatory with WebFinger.

I think the question was "Why was SWD created?" and Mike Jones gave this as
one of the reasons.



PEJ: I don't know. I wasn't aware of SWD until OpenID Connect was made more
visible.  I think it's rather unfortunate that we would not settle on one
protocol. Regardless of SWD or WF, we have a mechanism where we can query
for information about a user.  Having looked at both, I have a preference
for WF, because I get a set of link relations vs. having to ask the server
repeatedly for every single bit of info I hope the server might be able to
provide.  And I say that entirely without "invented here" bias, as I didn't
invent the WF protocol.


I'm not sure if there's much value in fighting it out.



PEJ: There is value in agreeing on one solution.

 

"It's possible to retrieve either host-meta.json or host-meta with "json"
Accept header. --> confusing?"

 

This should not be confusing and if it is, we need to clarify it in the
spec.  XRD is optional and JRD is mandatory.  If a server implements both
(as mine does), the default format returned by host-meta will be XRD and
host-meta.json is JRD.  If a server only supports JSON, it will likely
return JRD in response regardless.  Usually, that's how web services behave
with the Accept header.

I think the idea that came up was that we should just concentrate on the
/.well-known/host-meta.json endpoint for the Webfinger protocol (by which I
mean: additional resource and rel parameters).

It would simplify server implementations if I can just ignore resource and
rel for /.well-known/host-meta. It would also simplify client
implementations if they know always to use /.well-known/host-meta.json.



PEJ: The spec currently says clients "If a client wishes to receive only
JRDs, for example, it SHOULD issue a request to /.well-known/host-meta.json,
but MAY issue a request to /.well-known/host-meta and include the "Accept"
header with the type "application/json"."  If I were writing a client that
utilizes JSON, I would likely query the .json resource. To be compliant with
the spec, you know it will be on the server if the server supports JSON.
However, I do personally have a preference for XML.  And, there is a lot of
WF stuff out there using XML.  There is a tiny bit of work to support both
XML and JSON and even less work to support both resource addresses.  In
fact, I service both from a single script, using Apache rewriting rules to
just direct a request from one resource address to the other.  It's so
simple, it can even be run on a static site:
http://www.packetizer.com/webfinger/server.html.  But, client developers
absolutely can simplify their lives by just going straight to the .json
resource, and that's the advice given.  One does not have to guess about it.
(And, personally, I'd rather instruct users to make proper HTTP requests and
put in the Accept header, but I don't want to fight that one.)

 

"Questions about the case when multiple links/locations are discovered"

 

We might have to defer to others on this one, but my understanding is that
the order of links is the approach.  RFC 6415 is clear about ensuring that
order is always maintained.  Thus, in my implementation, I have an integer
value in the database and all data is sorted per that integer value.
Essentially, it is my "priority" value, but it does not appear in the
protocol.

 

There's not an explicit interpretation of having multiple links with the
same rel, like:

{
    links: [
        {
            rel:  <http://api.example/some-api>
"http://api.example/some-api",
            href:  <http://server1.example/endpoint>
"http://server1.example/endpoint"
        },
        {
            rel:  <http://api.example/some-api>
"http://api.example/some-api",
            href:  <http://server2.example/endpoint>
"http://server2.example/endpoint"
        }
    ]
}

I think the typical (?) interpretation is that both links are equally valid
and that the client can pick whichever they want. Most code I've seen will
either pick the first or last.

There are some systems where you can define priority for different members
of the list, like MX records in DNS. "Try the first endpoint, and if it
doesn't work try the next one, and then one of the next three at your
discretion."

It's probably an issue that should be worried about in the distant future.



PEJ: I really do think the first takes priority.  Per RFC 6415: "Note that
the order of links matters and is based on their original order in the
host-meta and LRDD documents."  That said, I believe order preference for
the client might differ.  If I am looking for information and see two
different domains, I might prefer to use one domain over another.  I just
made sure I produce documents in the prescribed order and let the client
decide what to do.

 

Paul


-Evan
    



-- 
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@status.net P: +1-514-554-3826