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

[Mike Jones <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Stephen Farrell
Sent: Friday, April 13, 2012 9:23 AM
To: [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> 
_______________________________________________
apps-discuss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/apps-discuss