Subject: [apps-discuss] WebFinger Discussion Points

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 02 May 2012 04:42:44 -0400

Folks,

I did not see (enough) follow-up on Blaine's message regarding 
WebFinger.  He raised three issues:

1) JSON vs. XML
2) JSON format
3) Direct vs.  Indirect (i.e., single query response with "resource" 
parameter)

I have no strong preferences to the point of derailing the project :-), 
but I would prefer:

1) The server is required to provide both XML and JSON formats, while 
the client can select what it wants
2) The JSON format should be the JRD format as described in RFC 6415
3) We should make the "resource" parameter a MUST in order to allow the 
client to be implemented such that it can make a single query to get the 
information it is seeking

I believe this would satisfy the requirements from the OpenID Connect 
team.  #3 would mean that current WebFinger servers are "broken" until 
they either:
1) Provide support in the WebFinger server code for the "resource" parameter
2) Use HTTP server re-writing rules (or similar) to handle the request.  
(See http://www.packetizer.com/webfinger/server.html for an example of 
how Apache can be used to allow a static site to support the "resource" 
parameter.)

The "rel" parameter is presently listed as optional and I see no reason 
to mandate it.  Mandating it only potentially reduces the size of the 
response. I think a SHOULD is enough.  Static sites cannot support  the 
"rel" parameter and they would likely have only a few link relations.

How is this for a way forward?  Any heartburn with this?

Paul

---

From: Mike Jones <[email-masked]>
Date: Wed, 2 May 2012 08:53:31 +0000

This seems like a way forward to me, Paul.  Thanks for picking the discussion back up.  (I suspect many of us were exhausted! ;-) )

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul E. Jones
Sent: Wednesday, May 02, 2012 1:43 AM
To: [email-masked]
Subject: [apps-discuss] WebFinger Discussion Points

Folks,

I did not see (enough) follow-up on Blaine's message regarding WebFinger.  He raised three issues:

1) JSON vs. XML
2) JSON format

I have no strong preferences to the point of derailing the project :-), but I would prefer:

1) The server is required to provide both XML and JSON formats, while the client can select what it wants
2) The JSON format should be the JRD format as described in RFC 6415
3) We should make the "resource" parameter a MUST in order to allow the client to be implemented such that it can make a single query to get the information it is seeking

I believe this would satisfy the requirements from the OpenID Connect team.  #3 would mean that current WebFinger servers are "broken" until they either:
1) Provide support in the WebFinger server code for the "resource" parameter
2) Use HTTP server re-writing rules (or similar) to handle the request.  
(See http://www.packetizer.com/webfinger/server.html for an example of how Apache can be used to allow a static site to support the "resource" 
parameter.)

The "rel" parameter is presently listed as optional and I see no reason to mandate it.  Mandating it only potentially reduces the size of the response. I think a SHOULD is enough.  Static sites cannot support  the "rel" parameter and they would likely have only a few link relations.

Paul

_______________________________________________
apps-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Wed, 2 May 2012 05:32:44 -0400

I too support this as a way forward.  I'm also of the mind that it would be most productive if we produce an -04 version of the WebFinger draft that incorporates these two changes (note #1 is already in the the -03 version of the WF draft) and can be the 'line in the sand' that we can adopt as a WG document. This base draft can be the foundation on which we build a discovery protocol that meets the needs of both WF and SWD camps.

Cheers,

Gonzalo

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 2 May 2012 12:06:14 +0200

> client can select what it wants

-1

I thought issue #1 was for JSON ONLY?  And only to reply if there was
anyone supporting XML.  I didnt see any replies.  I may have misunderstood
the whole thing tho.

I came across this video recently, entitled "Lessons of JSON"

http://inkdroid.org/journal/2012/04/30/lessons-of-json/

Douglas Crockford gives some insights into the advantages of JSON over XML.

> 2) The JSON format should be the JRD format as described in RFC 6415

I think I was the only person to reply to this point.

I'm curious as to why a bespoke almost unused MIME type

application/xrd+json

Rather than, the commonly used:

application/json

As per SWD

Is there a spec for JRD, other than Eran's blog post.  What's the licensing?

> team.  #3 would mean that current WebFinger servers are "broken" until they
> either:
>  (See http://www.packetizer.com/**webfinger/server.html<http://www.packetizer.com/webfinger/server.html>for an example of how Apache can be used to allow a static site to support
> the "resource" parameter.)
>

What are the typical values that resource can take?

Is resource=user@host acceptable, or is a scheme required?

In particular re acct:

Is the new scheme "acct" still proposed?  The documentation for the account
scheme is still incomplete as of
http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03

Should it have its own RFC, or folded into the new joint spec?  Personally,
I think documenting acct: is a bigger task than SWD itself.

If, once documented and reviewed, there is a consensus is for acct: is
taken forward, should it be a new URI scheme or a URN?

How does it relate to XMPP and email?  Are there possible collisions?

etc. etc.

>
> The "rel" parameter is presently listed as optional and I see no reason to
> mandate it.  Mandating it only potentially reduces the size of the
> ______________________________**_________________
> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 2 May 2012 12:11:00 +0200

> Is there a spec for JRD, other than Eran's blog post.  What's the

Ah I just found http://tools.ietf.org/html/rfc6415#appendix-A (thanks for
the pointer)

I'd still like to understand the motivation for creating a new flavor of
JSON (and MIME type) as per (WF) rather than using standard JSON (as per
SWD)

> Is the new scheme "acct" still proposed?  The documentation for the
> account scheme is still incomplete as of
> Should it have its own RFC, or folded into the new joint spec?
> Personally, I think documenting acct: is a bigger task than SWD itself.
>

---

From: Michiel de Jong <[email-masked]>
Date: Wed, 2 May 2012 12:14:41 +0200

On Wed, May 2, 2012 at 11:32 AM, Gonzalo Salgueiro <[email-masked]> wrote:
> it would be most productive if we produce an -04 version of the WebFinger draft that incorporates these two changes

+1

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 02 May 2012 07:03:44 -0400

On 5/2/2012 6:06 AM, Melvin Carvalho wrote:
>
>
> On 2 May 2012 10:42, Paul E. Jones <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Folks,
>
>     3) Direct vs.  Indirect (i.e., single query response with
>     "resource" parameter)
>
>     1) The server is required to provide both XML and JSON formats,
>     while the client can select what it wants
>
>
> -1
>
> anyone supporting XML.  I didnt see any replies.  I may have 
> misunderstood the whole thing tho.

He did call for JSON only.  However, RFC 6415 and current WebFinger 
servers use XML.  So, I don't think we should simply disregard those 
facts.  Supporting both on the server side is trivial, so I don't see a 
reason to not implement both.

> Rather than, the commonly used:

The media type "xrd+json" would not be right since a JRD is not XML.  We 
could define jrd+json, but this starts us down the path of having a 
gazillion whatever+json definitions like there with +xml definitions.  
I'll note that there are no standards in the IETF presently that define 
a whatever+json.  We would be the first and that gives me some concern.  
Is application/json an issue?

> Is there a spec for JRD, other than Eran's blog post.  What's the 

I noted you found this in your follow-up. It is in RFC 6415, as you noted.

>     3) We should make the "resource" parameter a MUST in order to
>     allow the client to be implemented such that it can make a single
>     query to get the information it is seeking
>
>     I believe this would satisfy the requirements from the OpenID
>     Connect team.  #3 would mean that current WebFinger servers are
>     "broken" until they either:
>     2) Use HTTP server re-writing rules (or similar) to handle the
>     request.  (See http://www.packetizer.com/webfinger/server.html for
>     an example of how Apache can be used to allow a static site to
>     support the "resource" parameter.)
>
>

The resource parameter would take any valid URI.

> Is resource=user@host acceptable, or is a scheme required?

It should always have a scheme, otherwise it would have no specific meaning.

> http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03

"acct" has been proposed for a long time now and documented in the 
WebFinger draft.  Why do you say it is incomplete?  What is missing, 
exactly?

> Personally, I think documenting acct: is a bigger task than SWD itself.

Since I don't know what you feel is missing, it's hard to argue 
otherwise :-)  We could move the acct URI to a different draft, but what 
would be the value?  It would just require people to hunt down even more 
documents.

> taken forward, should it be a new URI scheme or a URN?

Please note that "acct" is already implemented.  I think we should leave 
it as-is.

> How does it relate to XMPP and email?  Are there possible collisions?

This is precisely why we need "acct".  One's email address is one URI 
(mailto:) and one's XMPP address is another (xmpp:).  The "acct" URI 
refers to a user account and not their email address or XMPP address, 
etc.  You might query my Google+ account, for example, and discover that 
I have several different email addresses and XMPP addresses, but I have 
one Google+ account.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 02 May 2012 07:05:45 -0400

On 5/2/2012 6:11 AM, Melvin Carvalho wrote:
> Ah I just found http://tools.ietf.org/html/rfc6415#appendix-A (thanks 
> for the pointer)
>
> I'd still like to understand the motivation for creating a new flavor 
> of JSON (and MIME type) as per (WF) rather than using standard JSON 
> (as per SWD)

Why do you say this is a new flavor of JSON?  It's not.  It also uses 
the application/json media type as defined in RFC 4627.

Paul

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 2 May 2012 13:08:00 +0200

> How is this for a way forward?  Any heartburn with this?

One thing that would be a kind of joint problem statement, of the main
thing that's trying to be solved.

I think this started out as a way for webmail providers to give auxiliary
"follow your nose" style data linkage, using the "well known" pattern.

It's sort of morphed a bit into a few different things, such as a generic
discovery method for the net, a new uri scheme,  an account identity system
for the net, serialization formats.

All these things *can* be important, but there's already solutions in many
places, and overlap with existing technology.  The recent WWW 2012
conference has shown that structured data is now incoporated in somewhere
between 25% and 32% of the web, eg using RDFa and microdta.  Do we think
it's productive to push yet another data lookup format?

http://www.bbc.co.uk/blogs/researchanddevelopment/2012/04/notes-from-the-www12-conferenc.shtml

It would be awesome if we can main pain point, or problem statement that
these specs can solve, find out what the easy wins are, solve those with
minimum fuss, imho.

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 2 May 2012 13:14:40 +0200

On 2 May 2012 13:03, Paul E. Jones <[email-masked]> wrote:

> gazillion whatever+json definitions like there with +xml definitions.  I'll
> note that there are no standards in the IETF presently that define a
> whatever+json.  We would be the first and that gives me some concern.  Is
> application/json an issue?
>
>
>

Ah apologies I had been looking at a previous version:

   QUESTION: Do we want to restrict the acct: URI to only be user@domain
   and borrow the syntax from, say, the SIP spec?  Or, do we want to
   reference addr-spec as we have it now?

I see this is no longer in the current draft.  I guess this is now
resolved, let me look thru the current draft in more detail.

> Since I don't know what you feel is missing, it's hard to argue otherwise
> :-)  We could move the acct URI to a different draft, but what would be the
> value?  It would just require people to hunt down even more documents.
>
>
> refers to a user account and not their email address or XMPP address, etc.
> You might query my Google+ account, for example, and discover that I have
> several different email addresses and XMPP addresses, but I have one
> Google+ account.
>
> Paul
>
>

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 2 May 2012 13:18:21 +0200

> several different email addresses and XMPP addresses, but I have one

Thanks for the response, makes a lot of sense.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 02 May 2012 07:36:43 -0400

> thing that's trying to be solved.

Is this not understood?  Keep in mind that this was not fabricated last 
week.  I've been personally interacting with people working on WebFinger 
for a couple of years (or more) now.  The idea is all about discovery.  
Given a URI, what can you learn about it?  This resulted in the creation 
of the XRD spec, RFC 5785, RFC 6415 and perhaps other documents along 
the way.  Definitely, the web linking document (RFC 5988) is also an 
important part of this.

> I think this started out as a way for webmail providers to give 
> auxiliary "follow your nose" style data linkage, using the "well 
> known" pattern.

I don't know where it all started, but I got my start with OpenID.  I 
did not like entering https://openid.packetizer.com/paulej whenever I 
wanted to log in.  Rather, I wanted to enter [email-masked].  I 
was referred by folks on the OpenID list to go look at WebFinger.  And, 
here we are.

> It's sort of morphed a bit into a few different things, such as a 
> generic discovery method for the net, a new uri scheme,  an account 
> identity system for the net, serialization formats.

I don't think it has morphed.  These were things that needed to be 
defined to realize the vision.

> All these things *can* be important, but there's already solutions in 
> many places, and overlap with existing technology.  The recent WWW 
> 2012 conference has shown that structured data is now incoporated in 
> somewhere between 25% and 32% of the web, eg using RDFa and microdta.  
> Do we think it's productive to push yet another data lookup format?
>
> It would be awesome if we can main pain point, or problem statement 
> that these specs can solve, find out what the easy wins are, solve 
> those with minimum fuss, imho.

I'd argue there is nothing else in existence that can do what WebFinger 
does, modulo the competing SWD draft. That said, I think there is 
agreement to move forward with WebFinger to provide a single solution.

Are you arguing for a different data format?  I think it's worth 
highlighting the simplicity and beauty of the XRD/JRD representations.  
These formats primarily include a set of link relations.  The link 
relations are the same syntax and possible values as one might use in 
the "Link" header in HTTP and <link> tags in HTML.  So, WebFinger ties 
in very nicely with the Web.

Paul

---

From: Melvin Carvalho <[email-masked]>
Date: Thu, 3 May 2012 10:44:06 +0200

On 2 May 2012 13:36, Paul E. Jones <[email-masked]> wrote:

> of the XRD spec, RFC 5785, RFC 6415 and perhaps other documents along the
> way.  Definitely, the web linking document (RFC 5988) is also an important
> part of this.
>
>
> I don't know where it all started, but I got my start with OpenID.  I did
> not like entering https://openid.packetizer.com/**paulej<https://openid.packetizer.com/paulej>whenever I wanted to log in.  Rather, I wanted to enter
> [email-masked].  I was referred by folks on the OpenID list to go
> look at WebFinger.  And, here we are.

Yes I do remember the transition from Yadis to OpenID through 1.1 and to
2.0.  As you say there was a marked change.

Seems to be two polarizing world views.  One is to use email style
identifiers to describe things, the other is to use HTTP URIs to describe
things.  The UI choice need not necessarily influence the backend
architecture.  For example, facebook open graph uses HTTP URIs to define a
profile, but allows login with an email style identifier.

> I don't think it has morphed.  These were things that needed to be defined
> to realize the vision.
>
>
>> many places, and overlap with existing technology.  The recent WWW 2012
>> http://www.bbc.co.uk/blogs/**researchanddevelopment/2012/**
>> 04/notes-from-the-www12-**conferenc.shtml<http://www.bbc.co.uk/blogs/researchanddevelopment/2012/04/notes-from-the-www12-conferenc.shtml>
>>
> does, modulo the competing SWD draft. That said, I think there is agreement
> to move forward with WebFinger to provide a single solution.
>

I dont have any problem with moving forward with the WF draft, perhaps
taking the best features from both specs, is a great idea.  I'm just
interested on whether the combined problem statement will change, and the
extent to which, there will be any focus on email based lookup.

As an aside, in answer to your specific point.  Im curious, are you saying
that SPARQL, which has been a W3C rec, for a number of years, is incapable
of a query such as the ones covered by SWD or WF?

> relations are the same syntax and possible values as one might use in the
> "Link" header in HTTP and <link> tags in HTML.  So, WebFinger ties in very
> nicely with the Web.
>

Not trying to form opinion here.  Just to understand.  In structured data,
things can change pretty quickly, and we're all trying to hit a moving
target.  I do think it's sometimes helpful to look at what other
technologies are starting to gain adoption, in order to get a bigger
picture of the whole landscape, or how it might look in a few years.

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 03 May 2012 09:24:29 -0400

On 5/3/2012 4:44 AM, Melvin Carvalho wrote:
>
>
> On 2 May 2012 13:36, Paul E. Jones <[email-masked] 
>         One thing that would be a kind of joint problem statement, of
>         the main thing that's trying to be solved.
>
>
>     Is this not understood?  Keep in mind that this was not fabricated
>     last week.  I've been personally interacting with people working
>     on WebFinger for a couple of years (or more) now.  The idea is all
>     about discovery.  Given a URI, what can you learn about it?  This
>     resulted in the creation of the XRD spec, RFC 5785, RFC 6415 and
>     perhaps other documents along the way.  Definitely, the web
>     linking document (RFC 5988) is also an important part of this.
>
>
>         I think this started out as a way for webmail providers to
>         give auxiliary "follow your nose" style data linkage, using
>         the "well known" pattern.
>
>
>     I don't know where it all started, but I got my start with OpenID.
>      I did not like entering https://openid.packetizer.com/paulej
>     whenever I wanted to log in.  Rather, I wanted to enter
>     [email-masked] <mailto:[email-masked]>.  I was
>     referred by folks on the OpenID list to go look at WebFinger.
>      And, here we are.
>
>
> Yes I do remember the transition from Yadis to OpenID through 1.1 and 
> to 2.0.  As you say there was a marked change.
>
> identifiers to describe things, the other is to use HTTP URIs to 
> describe things.  The UI choice need not necessarily influence the 
> backend architecture.  For example, facebook open graph uses HTTP URIs 
> to define a profile, but allows login with an email style identifier.

Yeah, I agree with you entirely.  This is a topic for the OpenID list, 
perhaps, but I had no objection to having OpenID use a URI.  I just 
didn't want to enter it by hand :-)  Thus, using WebFinger as a 
discovery protocol to facilitate the mapping of a email-style address 
into an OpenID URI made a lot of sense.

>
>
>         It's sort of morphed a bit into a few different things, such
>         as a generic discovery method for the net, a new uri scheme,
>          an account identity system for the net, serialization formats.
>
>
>         All these things *can* be important, but there's already
>         solutions in many places, and overlap with existing
>         technology.  The recent WWW 2012 conference has shown that
>         structured data is now incoporated in somewhere between 25%
>         and 32% of the web, eg using RDFa and microdta.  Do we think
>         It would be awesome if we can main pain point, or problem
>         statement that these specs can solve, find out what the easy
>         wins are, solve those with minimum fuss, imho.
>
>
>     I'd argue there is nothing else in existence that can do what
>     WebFinger does, modulo the competing SWD draft. That said, I think
>     there is agreement to move forward with WebFinger to provide a
>     single solution.
>
>
> interested on whether the combined problem statement will change, and 
> the extent to which, there will be any focus on email based lookup.
>
> As an aside, in answer to your specific point.  Im curious, are you 
> saying that SPARQL, which has been a W3C rec, for a number of years, 
> is incapable of a query such as the ones covered by SWD or WF?

I'm not sure if it is capable or not, but I get the impression that 
SPARQL was not designed for that purpose.  I suppose if there is a way 
to query for multiple data elements and the entirety of what one might 
want to query is located at a known location, perhaps it could.  
WebFinger is intended to allow on to issue a query for any URI against 
the associated domain, including acct:, mailto:, https:, etc.  And the 
response is a simple set of link relations.  The process is so trivial I 
can implement a "server" using static files and use "curl" to fetch the 
data set.  Can SPARQL get information for any URI as WebFinger can?  For 
certain, if it can it does so with a lot more complexity.  I would need 
to see some examples, since those in the spec don't seem to be aligned 
with what WF or SWD do.

>     highlighting the simplicity and beauty of the XRD/JRD
>     representations.  These formats primarily include a set of link
>     relations.  The link relations are the same syntax and possible
>     values as one might use in the "Link" header in HTTP and <link>
>     tags in HTML.  So, WebFinger ties in very nicely with the Web.
>
>
> Not trying to form opinion here.  Just to understand.  In structured 
> data, things can change pretty quickly, and we're all trying to hit a 
> moving target.  I do think it's sometimes helpful to look at what 
> other technologies are starting to gain adoption, in order to get a 
> bigger picture of the whole landscape, or how it might look in a few 
> years.

This is one reason I think XRD/JRD are good, too.  One might represent 
data in a variety of formats (e.g., Portable Contacts vs. hCard vs. 
vCard vs. xcard).  WF does not dictate the format in which useful 
information is presented.  What it does is merely provide a pointer to 
that information.  It's that simplicity and data independence which I 
find appealing, as I can continue to use WF long after formats holding 
user data become obsolete.

Paul

---

From: Melvin Carvalho <[email-masked]>
Date: Fri, 4 May 2012 11:02:42 +0200

On 3 May 2012 15:24, Paul E. Jones <[email-masked]> wrote:

>>> auxiliary "follow your nose" style data linkage, using the "well known"
>>> pattern.
>>>
>>
> perhaps, but I had no objection to having OpenID use a URI.  I just didn't
> want to enter it by hand :-)  Thus, using WebFinger as a discovery protocol
> to facilitate the mapping of a email-style address into an OpenID URI made
> a lot of sense.
>
>
>
>
>>
>>
> I'm not sure if it is capable or not, but I get the impression that SPARQL
> was not designed for that purpose.  I suppose if there is a way to query
> for multiple data elements and the entirety of what one might want to query
> is located at a known location, perhaps it could.  WebFinger is intended to
> allow on to issue a query for any URI against the associated domain,
> including acct:, mailto:, https:, etc.  And the response is a simple set
> of link relations.  The process is so trivial I can implement a "server"
> using static files and use "curl" to fetch the data set.  Can SPARQL get
> information for any URI as WebFinger can?  For certain, if it can it does
> so with a lot more complexity.  I would need to see some examples, since
> those in the spec don't seem to be aligned with what WF or SWD do.
>

SPARQL is just a query language for data.  You can think of it a bit like a
jquery with a funny syntax.

It can reasonably easily handle questions like

"for an email address mailto:user@host, give me the blog of that subject"

or

"for an email address mailto:user@host, give me ALL information on that
subject"

or

"for a subject acct:user@host, give me ALL information on that subject"

etc. etc.

Toby Inkster wrote up how to do this back in 2009 and implemented it in
perl [1], which may be of interest to you

I guess one day XRD may have it's own general purpose query language which
would be a generalization of SWD/WF.  However, cant help but feel there's
an element of reinvention as 100s of man years of spec writing has gone
into SPARQL and Linked Data, so hopefully there's some elements that can be
reused.

[1] http://buzzword.org.uk/2009/fingerpoint/spec-in.html

*apologies if that link is sometimes down, I think it's hosted from his
home machine

> data in a variety of formats (e.g., Portable Contacts vs. hCard vs. vCard
> vs. xcard).  WF does not dictate the format in which useful information is
> presented.  What it does is merely provide a pointer to that information.
> It's that simplicity and data independence which I find appealing, as I can
> continue to use WF long after formats holding user data become obsolete.
>
> Paul
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 04 May 2012 05:46:45 -0400

On 5/4/2012 5:02 AM, Melvin Carvalho wrote:
> SPARQL is just a query language for data.  You can think of it a bit 
> like a jquery with a funny syntax.
>
> "for an email address mailto:user@host <mailto:user@host>, give me the 
> blog of that subject"
>
> or
>
> "for an email address mailto:user@host <mailto:user@host>, give me ALL 
> information on that subject"
>
> or
>
> Toby Inkster wrote up how to do this back in 2009 and implemented it 
> in perl [1], which may be of interest to you
>
> I guess one day XRD may have it's own general purpose query language 
> which would be a generalization of SWD/WF.  However, cant help but 
> feel there's an element of reinvention as 100s of man years of spec 
> writing has gone into SPARQL and Linked Data, so hopefully there's 
> some elements that can be reused.
>

Melvin,

This is interesting and I had not seen it before.  At the very least, it 
validates that there are even more people interested in solving this 
problem.

The approach has a lot of parallels to WF & SWD.  To figure out where to 
direct a query, one uses the domain name of an email address and issues 
a query to, for example, http://example.com/sparql.  This is similar to 
looking at /.well-known/host-meta.  WF would query host-meta for a 
document with link relations inside.  The "fingerpoint" spec looks for 
Link headers in the HTTP response, it seems.  This is the place where 
the similarities end, though.  At this stage, a WF client would have the 
link relations related to a person and could query each for documents 
(e.g., PoCo, vcard, avatar, etc.).  The "fingerpoint" protocol would 
only have a pointer to where it can then go issue a SPARQL query.  Next, 
one has to go issue a SPARQL query, which a lot like a web version of 
SQL.  This adds one more steps and also introduces SPARQL, which is not 
trivial by any means; it's a fairly powerful language.

So, I stand corrected that another protocol could not be used, but the 
alternative (SPARQL) does not fit the goal of trying to keep WF/SWD 
"simple", IMO.

Paul