Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

From: Mike Jones <[email-masked]>
Date: Fri, 13 Apr 2012 23:34:41 +0000

Thanks for the questions Hannes, and for your note, Stephen.   In response, I'll first provide a brief feature comparison of Simple Web Discovery and WebFinger, answer your questions, and then make some closing remarks.  I'd also suggest that people read http://www.goland.org/simplewebfinger/ and http://www.goland.org/managingfingerservice/ for background on the motivations for the choices in the Simple Web Discovery (SWD) protocol.

FEATURE COMPARISON

RESULT GRANULARITY AND PRIVACY CHARACTERISTICS:  SWD returns the resource location(s) for a specific resource for a specific principal.  As described in the current spec, WebFinger appears to return all resources for the principal, by default.  The example at http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-3.2 "Retrieving a Person's Contact Information" is telling.  As described, WebFinger usage model seems to be "I'll get everything about you and then look through it to decide what to do with it."  The assumption that WebFinger information is normally public also appears to be built into the protocol where the CORS response header "Access-Control-Allow-Origin: *" is mandated, per http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-7.  The default privacy characteristics of these approaches appear to be different.  (It's these very same privacy characteristics that led sysadmins to nearly ubiquitously disabling the fingerd service!)

SWD intentionally supports different permissioning on different resources for particular principals by reusing existing Internet mechanisms - specifically depending upon whether and how the requester is authenticated, different discovery requests may or may not be granted.  (In a recent OAuth thread, Blaine Cook pointed out that the set of resources returned by WebFinger could be filtered using the same mechanisms, which is true.  If that's the intent, I believe that should be made explicit in the WebFinger document.  And yes, we should make the intention to use Internet authentication mechanisms explicit in the SWD draft as well.)

DOCUMENT VERSUS API MODEL, DEPLOYABILITY:  WebFinger is built on a "document model", where a single document is returned that contains multiple resources for a principal.  SWD is built on an "API model", where the location(s) of a particular resource for a principal are returned.  The problem with the document model is that different parties or services may be authoritative for different resources for a given principal, and yet all need the rights to edit or provide portions of the resulting document.  This can hurt deployability, because document edits then need to be coordinated among parties that may have different rights and responsibilities.  (Just because I can change your avatar doesn't mean that I should be able to change your mail server.)

In a recent OAuth thread, Blaine Cook responded to this characterization by pointing out that the document model and the resource model are isomorphic, since Web documents can be and often are dynamically composed, which is certainly true.  If a document model is adopted that can return multiple resources, with different parties having different permissions to write to those resources, that effectively forces these documents to be dynamically composed by a service, for security and privacy reasons.  Of course that's doable, but seems less straight-forward to me.

REDIRECT FUNCTIONALITY AND DEPLOYABILTY:  SWD includes the ability to redirect some or all SWD requests to another location (possibly depending upon the specific resource and principal parameters).  Deployers hosting numerous sites for others told the SWD authors that this functionality is critical for deployability, as it means that the SWD server for a domain can live in a location outside the domain.

In the recent OAuth thread, Blaine Cook pointed out that WebFinger can accomplish this functionality through a different means - by having the result returned from the first host-meta query  direct the second query another server.  As such, I now believe both proposals can accomplish this goal.
 
NUMBER OF ROUND TRIPS:  WebFinger discoveries for user information normally require both a host-meta query to retrieve the template and then a second query to retrieve the user's information.  This functionality is achieved in a single SWD query.

In the recent OAuth thread, Blaine Cook argued that caching the first query result is likely to eliminate the first round trip in many cases.  That's very likely the case for multi-user and multi-tenant service deployments, but I suspect it's of little help to clients on personal devices, such as smart phones, using a high-latency channel, when UI response times are latency-dependent, and when most discoveries ARE first-time discoveries.

XML AND JSON VERSUS JSON:  WebFinger specifies both XML and JSON support, whereas SWD specifies only JSON.  I believe that it's simpler to specify only one way of doing the same thing, with JSON being chosen because it's simpler for developers to use than XML (the same decision as made for the OAuth specs, for what it's worth).

DEFINING SPECIFIC RESOURCES:  Besides specifying a discovery protocol, WebFinger also defines specific resources and kinds of resources to be used with that protocol:  the "acct" URI scheme and the "acct" Link Relation.  I'm happy to have these be considered on their own merits, but I believe that logically, they should be decoupled from the discovery protocol into a different document or documents.

HANNES' QUESTIONS

1) Aren't these two mechanisms solving pretty much the same problem?

	They are solving an overlapping set of problems, but with somewhat different mechanisms and characteristics.

2) Do we need to have two standards for the same functionality?

	I believe there's consensus that a single standard should suffice and is preferable.

3) Do you guys have a position or comments regarding either one of them?

	I believe that SWD is a simpler and reasonable base to start with for standardization.

CLOSING

I'll close by saying that I believe the authors of both proposals believe that this work is incredibly important for the Internet and we share the goals of making the resulting solution as simple, as deployable, and as ubiquitously adopted as possible and of producing it in a timely manner.  I look forward to working with them and the rest of the working group to make that happen.

                                                            -- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Friday, April 13, 2012 9:23 AM
To: [email-masked] WG
Cc: Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

Hi All,

So Hannes and Derek and I have been discussing this with the Apps ADs and Apps-area WG chairs. I've also read the docs now, and after all that we've decided that this topic (what to do with swd and webfinger) is best handled in the apps area and not in the oauth WG.

The logic for that is that 1) the two proposals are doing the same thing and we don't want two different standards for that, b) this is not an oauth-specific thing nor is it a general security thing, and c) there is clearly already interest in the topic in the apps area so its reasonable for the oauth wg to use that when its ready.

The appsawg chairs and apps ADs are ok with the work being done there.

So:-

- I've asked the oauth chairs to take doing work on swd
  out of the proposed new charter
- It may be that you want to add something saying that
  oauth will use the results of work in the applications
  area on a web discovery protocol as a basis for doing
  the dynamic client registration work here
- Discussion of webfinger and swd should move over to
  the apps-discuss list
- Note: this is not picking one or the other approach,
  the plan is that the apps area will do any selection
  needed and figure out the best starting point for a
  standards-track RFC on web discovery and we'll use their
  fine work for doing more with oauth.

Regards,
Stephen.

On 04/12/2012 12:00 PM, Hannes Tschofenig wrote:
> Hi all,
> 
> those who had attended the last IETF meeting may have noticed the ongoing activity in the 'Applications Area Working Group' regarding Web Finger. 
> We had our discussion regarding Simple Web Discovery (SWD) as part of the re-chartering process. 
> 
> Here are the two specifications:
> http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03
> http://tools.ietf.org/html/draft-jones-simple-web-discovery-02
> 
> Now, the questions that seems to be hanging around are
> 
>  1) Aren't these two mechanisms solving pretty much the same problem?
>  2) Do we need to have two standards for the same functionality?
>  3) Do you guys have a position or comments regarding either one of them? 
> 
> Ciao
> Hannes
> 
> PS: Please also let me know if your view is: "I don't really know what all this is about and the documents actually don't provide enough requirements to make a reasonable judgement about the solution space."
> 
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
> 
_______________________________________________
apps-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Bob Wyman <[email-masked]>
Date: Mon, 16 Apr 2012 14:45:25 -0400

On Fri, Apr 13, 2012 at 7:34 PM, Mike Jones <[email-masked]>wrote:

> Thanks for the questions Hannes, and for your note, Stephen.   In
> response, I'll first provide a brief feature comparison of Simple Web
> Discovery and WebFinger, answer your questions, and then make some closing
> remarks.  I'd also suggest that people read
> http://www.goland.org/simplewebfinger/ and
> http://www.goland.org/managingfingerservice/ for background on the
> motivations for the choices in the Simple Web Discovery (SWD) protocol.
>
> FEATURE COMPARISON
>
> RESULT GRANULARITY AND PRIVACY CHARACTERISTICS:  SWD returns the resource
> location(s) for a specific resource for a specific principal.  As described
> in the current spec, WebFinger appears to return all resources for the
> principal, by default.  The example at
> http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-3.2"Retrieving a Person's Contact Information" is telling.  As described,
> WebFinger usage model seems to be "I'll get everything about you and then
> look through it to decide what to do with it."  The assumption that
> WebFinger information is normally public also appears to be built into the
> protocol where the CORS response header "Access-Control-Allow-Origin: *" is
> mandated, per
> http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-7.
>  The default privacy characteristics of these approaches appear to be
> different.  (It's these very same privacy characteristics that led
> sysadmins to nearly ubiquitously disabling the fingerd service!)
>
> SWD intentionally supports different permissioning on different resources
> for particular principals by reusing existing Internet mechanisms -
> specifically depending upon whether and how the requester is authenticated,
> different discovery requests may or may not be granted.  (In a recent OAuth
> thread, Blaine Cook pointed out that the set of resources returned by
> WebFinger could be filtered using the same mechanisms, which is true.  If
> that's the intent, I believe that should be made explicit in the WebFinger
> document.  And yes, we should make the intention to use Internet
> authentication mechanisms explicit in the SWD draft as well.)
>
> DOCUMENT VERSUS API MODEL, DEPLOYABILITY:  WebFinger is built on a
> "document model", where a single document is returned that contains
> multiple resources for a principal.  SWD is built on an "API model", where
> the location(s) of a particular resource for a principal are returned.

One of the nice things about WebFinger is that it can return, in a single
response, "all that is known" about a particular entity or principle --
whether or not the requester anticipated that some link might exist. But,
it seems to me that with SWD, one needs to anticipate what is available
and, if you want to know many things, you need to issue many requests. But,
even if you do issue many requests, you might not get "all that is known."
This means that there is some serendipity lost... As a developer I don't
have the opportunity to notice that some particular kind of link is
appearing in WebFinger documents and then going through the discovery
process of figuring out what the new stuff is. Thus, I would expect that
the pace of innovation would be lower in an SWD based world than in one
that relies on WebFinger.

One might "fix" this aspect of SWD by defining an "all that is known"
service that returns lots of data, but if you did, you would have basically
re-invented WebFinger...

>  The problem with the document model is that different parties or services
> may be authoritative for different resources for a given principal, and yet
> all need the rights to edit or provide portions of the resulting document.
>  This can hurt deployability, because document edits then need to be
> coordinated among parties that may have different rights and
> responsibilities.  (Just because I can change your avatar doesn't mean that
> I should be able to change your mail server.)
>
> In a recent OAuth thread, Blaine Cook responded to this characterization
> by pointing out that the document model and the resource model are
> isomorphic, since Web documents can be and often are dynamically composed,
> which is certainly true.  If a document model is adopted that can return
> multiple resources, with different parties having different permissions to
> write to those resources, that effectively forces these documents to be
> dynamically composed by a service, for security and privacy reasons.  Of
> course that's doable, but seems less straight-forward to me.
>
> REDIRECT FUNCTIONALITY AND DEPLOYABILTY:  SWD includes the ability to
> redirect some or all SWD requests to another location (possibly depending
> upon the specific resource and principal parameters).  Deployers hosting
> numerous sites for others told the SWD authors that this functionality is
> critical for deployability, as it means that the SWD server for a domain
> can live in a location outside the domain.
>
> In the recent OAuth thread, Blaine Cook pointed out that WebFinger can
> accomplish this functionality through a different means - by having the
> result returned from the first host-meta query  direct the second query
> another server.  As such, I now believe both proposals can accomplish this
> goal.
>
> NUMBER OF ROUND TRIPS:  WebFinger discoveries for user information
> normally require both a host-meta query to retrieve the template and then a
> second query to retrieve the user's information.  This functionality is
> achieved in a single SWD query.
>
> In the recent OAuth thread, Blaine Cook argued that caching the first
> query result is likely to eliminate the first round trip in many cases.
>  That's very likely the case for multi-user and multi-tenant service
> deployments, but I suspect it's of little help to clients on personal
> devices, such as smart phones, using a high-latency channel, when UI
> response times are latency-dependent, and when most discoveries ARE
> first-time discoveries.
>
> XML AND JSON VERSUS JSON:  WebFinger specifies both XML and JSON support,
> whereas SWD specifies only JSON.  I believe that it's simpler to specify
> only one way of doing the same thing, with JSON being chosen because it's
> simpler for developers to use than XML (the same decision as made for the
> OAuth specs, for what it's worth).
>
> DEFINING SPECIFIC RESOURCES:  Besides specifying a discovery protocol,
> WebFinger also defines specific resources and kinds of resources to be used
> with that protocol:  the "acct" URI scheme and the "acct" Link Relation.
>  I'm happy to have these be considered on their own merits, but I believe
> that logically, they should be decoupled from the discovery protocol into a
> different document or documents.
>
> HANNES' QUESTIONS
>
>         They are solving an overlapping set of problems, but with somewhat
> different mechanisms and characteristics.
>
> I'll close by saying that I believe the authors of both proposals believe
> that this work is incredibly important for the Internet and we share the
> goals of making the resulting solution as simple, as deployable, and as
> ubiquitously adopted as possible and of producing it in a timely manner.  I
> look forward to working with them and the rest of the working group to make
> that happen.
>
>                                                            -- Mike
>
> So Hannes and Derek and I have been discussing this with the Apps ADs and
> Apps-area WG chairs. I've also read the docs now, and after all that we've
> decided that this topic (what to do with swd and webfinger) is best handled
> in the apps area and not in the oauth WG.
>
> The logic for that is that 1) the two proposals are doing the same thing
> and we don't want two different standards for that, b) this is not an
> oauth-specific thing nor is it a general security thing, and c) there is
> clearly already interest in the topic in the apps area so its reasonable
> for the oauth wg to use that when its ready.
>
> > those who had attended the last IETF meeting may have noticed the
> ongoing activity in the 'Applications Area Working Group' regarding Web
> Finger.
> > PS: Please also let me know if your view is: "I don't really know what
> all this is about and the documents actually don't provide enough
> requirements to make a reasonable judgement about the solution space."
> >
> >
> >
> >

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 17 Apr 2012 17:41:37 -0400

Mike, et al,

Sorry for the belated response.  I've been out of the office for a few days.

> location(s) for a specific resource for a specific principal.  As
> described in the current spec, WebFinger appears to return all resources
> for the principal, by default.  The example at
> http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-3.2
> "Retrieving a Person's Contact Information" is telling.  As described,
> protocol where the CORS response header "Access-Control-Allow-Origin: *"
> is mandated, per http://tools.ietf.org/html/draft-jones-appsawg-webfinger-
> 03#section-7.  The default privacy characteristics of these approaches
> appear to be different.  (It's these very same privacy characteristics
> that led sysadmins to nearly ubiquitously disabling the fingerd service!)

To be clear, WebFinger publishes links to information about people, not the
information about a person.  So, I might publish a link to my contact
information, access to that URL might be protected in some way.  Further,
the contents returned may vary depending on access rights.  In an
enterprise, for example, I would expect a response to one's Portable
Contacts information to be different than what might be shared externally.
However, those decisions are separate from WebFinger: it's policies applied
to different resources referenced by WebFinger.

In general, WebFinger will provide a complete list of link relations.
Again, this might be restricted in some cases (e.g., external vs. internal
query), but may not be.

> specifically depending upon whether and how the requester is
> authenticated, different discovery requests may or may not be granted.
> (In a recent OAuth thread, Blaine Cook pointed out that the set of
> resources returned by WebFinger could be filtered using the same
> mechanisms, which is true.  If that's the intent, I believe that should be
> made explicit in the WebFinger document.  And yes, we should make the
> intention to use Internet authentication mechanisms explicit in the SWD
> draft as well.)

I think you are saying that /.well-known/simple-web-discovery is a protected
resource, correct?  As noted above, one could equally protect
/.well-known/host-meta and the LRDD resource.  There is nothing that
restricts the use of various HTTP authorization mechanisms w.r.t. Host
Metadata or LRDD.  For WebFinger or SWD to be a useful Internet service,
though, a provider of information should share some link relations publicly.
Still, the choice is up to the provider of that information.
 
> may be authoritative for different resources for a given principal, and
> yet all need the rights to edit or provide portions of the resulting
> document.  This can hurt deployability, because document edits then need
> to be coordinated among parties that may have different rights and
> responsibilities.  (Just because I can change your avatar doesn't mean
> that I should be able to change your mail server.)

The document to which you refer is merely the collection of link relations
returned about a principal.  Whether one queries for a specific link
relation ("service") or all link relations, you have the same problem: the
link relations and type of link relation related to a principal must be
known to the /.well-known/<whatever> service.

The people involved in defining WebFinger elected to return all link
relations by default, allowing the client to select the one(s) it wanted to
use.  I personally find that very attractive, since I would not have to
issue multiple queries to find information stored as vcard, Portable
Contacts, etc.  If there is a specific link relation of interest,
identifying that is trivial.

So, both proposals on the table return a "document".  The difference is the
amount of information (i.e., the number of links) provided by default, I
think.
 
> course that's doable, but seems less straight-forward to me.

With my own WebFinger implementation, all link relations and link relation
types are pulled out of a database upon request.  Input into that database
is an entirely different function separate from WebFinger itself.

Are you concerned about how the server learns about link relations, or are
you concerned with how a particular web resource referenced by those link
relations is updated?  These are different steps.  It seems that with either
SWD or WebFinger, the challenges are the same.

> can live in a location outside the domain.

Well, that's the whole point of a link relation.  WebFinger does not return
user data.  Rather, it just points at that user data.  Query for information
about me and the link relations returned might point to one or more domains.
I can change a link relation anytime.

If a user's account is moved from one location to another (i.e., his/her
WebFinger information moves to a different domain), then a 3xx response
might be returned.  However, I personally see now value in having a
"redirect" at a link relation level when the link relation can be changed
and when the target resource (e.g., a URL to my picture) can also return a
3xx.

> another server.  As such, I now believe both proposals can accomplish this

There is that (as I also noted above) plus the ability to cross reference
user accounts using the "acct" link relation.  This is not intended for
non-"acct" URI queries, though.  Also, I would not use this in place of a
3xx.  However, if a user of a social networking service would allow users to
discover information about themselves at another social networking service,
this could be used.  (Today, it's possible to "link" accounts on social
networking sites, and this "acct" link relation is there to help automate
the sharing of that distributed information.)
 
> normally require both a host-meta query to retrieve the template and then
> a second query to retrieve the user's information.  This functionality is

This was one of the first comments we received between the -00 and -01
drafts of the WebFinger spec.  To address that, we introduced the "resource"
parameter.  This is backward-compatible with the current RFC 6415, but can
reduce round-trips.  Something to consider is mandating support for the
"resource" parameter.  It's fairly easy to support, but since there are
existing implementations, we may not be able to make support a MUST.
However, it would be easier to make this a MUST than to introduce a whole
different mechanism like SWD.

I view the round-trips for WebFinger to be trivial with or without the
resource parameter as compared to SWD.  SWD does return a URL in a single
request/response exchange.  However, what if I want to know several pieces
of information?  With SWD, I would have to issue multiple requests, one
request for each "service".  Doing that means the number of round-trips can
go up significantly.
 
> response times are latency-dependent, and when most discoveries ARE first-
> time discoveries.

I agree that we should try to reduce the roundtrips.  We've done that, but
we can discuss the strength to apply to the "resource" parameter (SHOULD vs.
MUST).
 
> OAuth specs, for what it's worth).

One syntax being simpler than another is a matter of opinion.  Some prefer
XML.  I prefer XML personally, but I'll note that I had nothing to do with
the decision to use XML in the first place.

In RFC 6415, JSON was there as an option.  In discussions with folks before
and since that RFC was published, there was a strong desire to support JSON.
So, we made it mandatory in the WebFinger spec.

It is important to note that support for XML and JSON is only a server-side
burden, not a client burden.  The client can use what it prefers.  I think
that's significant.  The complexity on the server is easily managed.  I
support both XML and JSON in my implementation and it was hardly no effort
at all.

> WebFinger also defines specific resources and kinds of resources to be
> used with that protocol:  the "acct" URI scheme and the "acct" Link
> Relation.  I'm happy to have these be considered on their own merits, but
> I believe that logically, they should be decoupled from the discovery
> protocol into a different document or documents.

This perhaps gets at the heart of "what is WebFinger?"  We already have a
discovery mechanism defined in the IETF.  It is RFC 6415.  Introducing SWD
at this point is throwing out all of the work that has already been done
over the past several years.

So, why did we introduce WebFinger?  We had several reasons:
1) We wanted to focus on the discovery of information about humans, so we
introduced the "acct" URI.  This has been discussed for a few years, too,
and it took a lot of debate to reach some agreement on the use of 'acct' vs
'mailto' vs no URI scheme vs. something else.
2) We wanted to require implementation of JSON
3) Noting that discovery within the enterprise might be different than the
public Internet, some wanted to mandate support for CORS (to which we have
had only support for thus far)
4) We wanted to allow a user to cross-reference social networking accounts,
so we introduced the 'acct' link relation
5) We wanted to optimize the discovery process (thus the "resource" and
"rel" parameters)

We did this through the WebFinger draft as we viewed all of those as natural
extensions to the existing discovery protocol documented in RFC 6415,
primarily, but not exclusively, aimed at discovery of information about
people.

> different mechanisms and characteristics.

I think they're trying to solve the same problem.
 
> 	I believe there's consensus that a single standard should suffice

Agreed.

> 	I believe that SWD is a simpler and reasonable base to start with

I don't agree one is really simpler than the other.  The "document" returned
by SWD (dare I say that, since you said that it's not document-oriented...
but it does return a document) is simpler, but the protocol is not simpler
or more difficult.  Both use HTTP to send a request to a known resource to
get a pointer to another resource.

SWD is more "complex" in that it requires multiple queries to get all
desired information.
WebFinger is more "complex" in that it might return more information than
requested.

Personally, I appreciate the more richer document produced by WebFinger.
Let me give a couple of examples.

Suppose I have three profile pictures that I would like to share with the
world.  I can share all three via WebFinger in order of preference.  The
receiving client can choose the first or give the requesting user the option
to use whatever picture the requesting user prefers.  SWD cannot return
three pictures, since it can return only a single response to any request
for a given "service" type.

Suppose I want to create a profile page like this:
https://plus.google.com/u/0/103173924987331945891

The data there all comes from what I've provided Google, but let's suppose
this is assembled from multiple sources.  To get a my current address,
picture, postings, friends, etc., one would have to issue multiple queries
using SWD, perhaps with service names that are not supported (thus, a few
404 responses).  I could get links to everything via WebFinger, allowing the
client to select to use vcard, hcard, portable contacts, or other
information it finds in the response.  Production of the page would go much
faster and would be simpler to implement.

If the client is only looking for a very specific link relation (as seems to
be the usage examples in SWD), that's easily done in WebFinger.  It would
only be a matter of looking at the set of returned link relations for the
specific one sought.  Stepping through an array of link relations is not
that complex.

> ubiquitously adopted as possible and of producing it in a timely manner.
> I look forward to working with them and the rest of the working group to
> make that happen.

On this, I think we are all in agreement.  This is a very important new
technology that we believe has great potential both within an enterprise and
on the public Internet.  WebFinger has already been implemented as a part of
Google+ and I would expect others to follow.

I think it's also worth mentioning again that WebFinger is a continuation of
work that has spanned years.  This work has already resulted in publication
of RFC 6415.  The current WebFinger draft exists for the reasons I stated
above.  I do not think we should just discard that effort without serious
justification.

Paul