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

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 12 Apr 2012 14:00:07 +0300

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."

---

From: Michiel de Jong <[email-masked]>
Date: Thu, 12 Apr 2012 13:45:33 +0200

Kudos for bringing this up!

imho, "speccers gonna spec" and it's impossible to stop overlapping
specs from showing up all the time. we'll have to live with the
existence of multiple standards.

Clients will just have to stand above whatever political reasons lie
behind them, and support both, just like DVD players often play like 8
different types of disc formats. We'll just have to query both, and
merge the information we find.

There are three important points regarding the differences between them, imho:
- webfinger mentions CORS, meaning that unlike swd it can be queried
by unhosted html5 apps, and not just server-to-server.
- swd mentions 401 responses, meaning that unlike webfinger, it can be
used to announce information to a limited audience, and not just
public data.
- webfinger starts at /.well-known/host-meta but swd starts at
/.well-known/simple-web-discovery, meaning a relying party will have
to choose which one to check first, and then check the other one in
case additional information lurks there. It would be nice if at least
that part could be reconciled. E.g. if swd requires providers to
(also) be discoverable through host-meta. That way there's one entry
point for both formats. Wouldn't that be nice?

My 2ct,
Michiel.

On Thu, Apr 12, 2012 at 1:00 PM, Hannes Tschofenig
<[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Apr 2012 13:01:59 +0100

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.
 > 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."

So just as a data-point. We (the IETF, but including
me personally;-) mucked up badly on this some years
ago in the PKI space - we standardised both CMP (rfc
2510) and CMC (rfc 2797) as two ways to do the same
thing, after a protracted battle between factions
supporting one or the other. We even made sure they
had as much common syntax as possible. (CRMF, rfc
2511)

Result: neither fully adopted, lots of people still
do proprietary stuff, neither can be killed off
(despite attempts), both need to be maintained (CMP
is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO
partly as a result of us screwing up for what seemed
like good reasons at the time, PKI administration
stuff has never gotten beyond horrible-to-do.

All-in-all, a really bad outcome which is still
a PITA a dozen years later.

As OAuth AD I will need *serious* convincing that
there is a need to provide two ways to do the same
thing. I doubt it'll be possible to convince me,
in fact, so if you wanna try, you'll need to start
by saying that they are not in fact two ways to do
the same thing:-)

S.

PS: This discussion needs to also involve the Apps
area, so I've cc'd that list.

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 12 Apr 2012 13:33:53 -0400

To me this looks like more than the same problem being solved--it 
appears to be the same protocol... I wonder if, the representation 
issues were put aside (i.e., left to the API specification), the common 
part is what can be adopted.

Igor

On 4/12/2012 8:01 AM, Stephen Farrell wrote:
> ongoing activity in the 'Applications Area Working Group' regarding 
> Web Finger.

---

From: John Bradley <[email-masked]>
Date: Thu, 12 Apr 2012 20:00:55 +0200

There are important deployment and privacy issues that caused openID Connect to use SWD.

I was part of the OASIS XRI/XRD work that Web Finger has been based on.

The main differences are around allowing all of the users information to be publicly discoverable, vs providing for access control. 

They are similar, but have real design differences.

Web Finger without XML is not horrible by any means,  but nether is SWD.

SWD is more about users while host-meta is more about server resources.

John B.

On 2012-04-12, at 7:33 PM, Igor Faynberg wrote:

> To me this looks like more than the same problem being solved--it appears to be the same protocol... I wonder if, the representation issues were put aside (i.e., left to the API specification), the common part is what can be adopted.
> 
> Igor
>

---

From: Eran Hammer <[email-masked]>
Date: Thu, 12 Apr 2012 18:18:08 +0000

Where is this access control and user centric architecture described? I could not find it. 

EH

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 12 Apr 2012 14:29:15 -0400

John,

  I agree with you on everything you said about the differences.  My 
question: Are these not about API rather than the protocol?

(I was just trying to see if I can find a common fixed point to start with.)

Igor

---

From: John Bradley <[email-masked]>
Date: Thu, 12 Apr 2012 20:31:23 +0200

SWD takes more of a API approach where a query is made about a specific resource type about a specific subject (email format or URI ).

The current draft of the spec doesn't go into detail on how a requester is identified and given authorization to discover the resource.   One could imagine that being done with OAuth. 

You could do a similar thing with web finger, however given that the typical deployment is more of a document model, that is harder for some large sites to deploy. 

Is everything in SWD fully sorted out, well no otherwise it would not be bing brought to the IETF for standardization.

As we discussed in Paris many of the goals are similar but there are implementation differences. 

I could also say that the Web Finger approach is more user-centric for sites where users have direct control over editing there own pages.    

In most cases, that is not the reality however. 

John B.

---

From: John Bradley <[email-masked]>
Date: Thu, 12 Apr 2012 21:56:59 +0200

There is no reason that SWD would not be a host service that host-meta could list like any other.

That should be supported now by the host-meta spec.  

The question is client complexity.   

A client could look in host-meta and do SWD if it finds that service and no mapping template, or the other way around.  

The question is do we want to add the complexity to clients where they have to support multiple discovery specs.

I seem to recall people calling me the devil for XRI resolution in openID 2.0.
Not to offend but Web Finger is XRI resolution without the central registry.

John B.

On 2012-04-12, at 8:29 PM, Igor Faynberg wrote:

> John,
> 
> I agree with you on everything you said about the differences.  My question: Are these not about API rather than the protocol?
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 12 Apr 2012 21:51:22 +0000

Thanks for asking these questions Hannes.  I'll first provide a brief feature comparison of Simple Web Discovery and WebFinger and then answer your questions.

FEATURE COMPARISON

RESULT GRANULARITY AND PRIVACY CHARACTERISTICS:  SWD returns the resource location(s) for a specific resource for a specific principal.  WebFinger returns all resources for the principal.  The example at http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-3.2 "Retrieving a Person's Contact Information" is telling.  The WebFinger usage model seems to be "I'll get everything about you and then fish through it to decide what to do with it."  The protocol assumption that all WebFinger information must be public is also 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 privacy characteristics of these approaches are very different.  (It's these very same privacy characteristics that led sysadmins to nearly ubiquitously disabling the fingerd service!)  Particularly for the OAuth use cases, narrow, scoped, and potentially permissioned responses seem preferable.

DOCUMENT VERSUS API MODEL, DEPLOYABILITY, AND SECURITY:  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 the resulting document.  This hurts deployability, because document edits then need to be coordinated among parties that may have different rights and responsibilities, and may have negative security implications as well.  (Just because I can change your avatar doesn't mean that I should be able to change your mail server.)

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.  WebFinger is lacking this functionality.  Given that OAuth is likely to be used in hosted environments, this functionality seems pretty important.

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.

XML AND JSON VERSUS JSON:  WebFinger specifies both XML and JSON support, whereas SWD specifies only JSON.  The SWD position is 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.

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, the "acct" Link Relation.  These should be considered on their own merits, but logically should be decoupled from the discovery protocol into a different document or documents.  It's not clear these features would be needed in OAuth contexts.

QUESTIONS

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

               No - Simple Web Discovery is sufficient for the OAuth use cases (and likely for others as well).

               The functionality in Simple Web Discovery is minimal and sufficient for the OAuth use cases, whereas some of the functionality and assumptions made in WebFinger are harmful, both from a privacy and from a deployability perspective.  SWD should proceed to standardization; WebFinger should not.

                                                            -- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, April 12, 2012 4:00 AM
To: [email-masked] WG
Subject: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

Hi all, 

Ciao
Hannes

---

From: Blaine Cook <[email-masked]>
Date: Thu, 12 Apr 2012 18:40:43 -0400

On 12 April 2012 17:51, Mike Jones <[email-masked]> wrote:

> Thanks for asking these questions Hannes.  I'll first provide a brief
> feature comparison of Simple Web Discovery and WebFinger and then answer
> your questions.
>
> FEATURE COMPARISON
>
> RESULT GRANULARITY AND PRIVACY CHARACTERISTICS:  SWD returns the resource
> location(s) for a specific resource for a specific principal.  WebFinger
> returns all resources for the principal.  The example at
> http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-3.2"Retrieving a Person's Contact Information" is telling.  The WebFinger
> usage model seems to be "I'll get everything about you and then fish
> through it to decide what to do with it."  The protocol assumption that all
> WebFinger information must be public is also 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 privacy characteristics of these approaches are very different.  (It's
> these very same privacy characteristics that led sysadmins to nearly
> ubiquitously disabling the fingerd service!)  Particularly for the OAuth
> use cases, narrow, scoped, and potentially permissioned responses seem
> preferable.
>

This is absolutely false.

SWD provides no privacy whatsoever. SWD makes it somewhat harder to crawl
large numbers of profiles, but it does not incorporate any real security,
and any attempt to suggest that it does is misleading and deceptive.

Webfinger, like any good HTTP service, is designed to allow access control
using appropriate means. That access control should not be *bound* to the
protocol, in the same way that HTTP does not have any REQUIRED access
control mechanisms, since doing so would severely restrict future usage of
a core protocol.

FUD has no place in a discussion of the technical and social merits of a
protocol.

For what it's worth, my intent with webfinger *from day one, nearly four
years ago*, has been to provide permissioned profile data *using EXISTING*
(or new, where appropriate or necessary, based on *running code and
deployment EXPERIENCE*) access control mechanisms for profile data.

The idea that there is ONE view of the data is patently false. For example,
depending on who is requesting my profile data, I might return different
contact telephone numbers, and this behaviour is completely feasible using
webfinger.

> DOCUMENT VERSUS API MODEL, DEPLOYABILITY, AND SECURITY:  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 the resulting document.
>  This hurts deployability, because document edits then need to be
> coordinated among parties that may have different rights and
> responsibilities, and may have negative security implications as well.
>  (Just because I can change your avatar doesn't mean that I should be able
> to change your mail server.)
>

WS-* was built on an API model, and that worked out very well.

APIs and documents on the web are the same thing; how you represent them
behind the scenes is up to you, and that's been a core principle of the web
since shortly after its inception. Suggesting otherwise profoundly
misunderstands how implementation of web services happens.

SWD says nothing of how to update profile data, so the security concerns
here are a total red herring.

> 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.  WebFinger is lacking this
> functionality.  Given that OAuth is likely to be used in hosted
> environments, this functionality seems pretty important.
>

Umm, I'm not even sure what to say to this. host-meta is a static file that
points to a profile server (generally expected to be a dynamic "API"
server) that can be hosted on any domain.

The fact that you're suggesting that this core piece of webfinger
functionality is *missing* seriously undermines my belief that you're
acting in good faith, Mike.

> 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.
>

... at the cost of greater client complexity. A webfinger lookup may be
implemented with the following trivial shell script:

curl -s http://example.com/.well-known/host-meta|awk "/lrdd/,/template/"|tr
-d '\n'|sed -e "s/^.*template='\([^']*\)'.*$/\1/"|sed -e "s/{uri}/
[email-masked]/"|xargs curl -s

so long as your HTTP client properly follows redirects, this approach will
always produce a valid webfinger profile, and if proper caching is
implemented, will only make requests to /.well-known/host-meta when the
document is expired.

SWD, on the other hand, implements a non-HTTP redirect mechanism, meaning
that optimal caching rules can't be obeyed by standard HTTP clients.
Moreover, SWD *requires* conditionals by presenting one code path for the
non-redirect case and one code path for the immediate response case.

The complexity for client implementations should be foremost in this work,
and the decisions made by SWD don't indicate to me that these factors have
been considered.

Indeed, I wonder why is SWD designed to pre-optimize for presumed scaling
challenges that are faced by only the very largest providers (namely, the
fact that two lookups are required for webfinger instead of one in the
ideal case), when:

1. Those scaling challenges are simply not real threats. host-meta can be
cached using existing HTTP mechanisms
2. The fact that SWD only returns one service definition per request means
that more than one request will often be required to obtain the necessary
information about a user.
3. The chances that Google or Microsoft will host dynamic response SWD
services on the gmail.com or hotmail.com domains is next to nil, and will
therefore need to issue redirects anyways.

For smaller providers (e.g., personal domains hosted in static or rigid
environments), hosting a SWD server at /.well-known/simple-web-discovery
may be challenging indeed. Thus, all clients will need to support the
redirect behaviour natively, and for those who write specs but not code, it
is *more* complex to have conditional behaviour like that than to have a
defined flow that is always followed.

Further, it's more complex for small service providers to host static
content that is invariant and properly cached (e.g., by transparent proxy
caches like varnish and squid) when CGI parameters are appended, as with
SWD.

XML AND JSON VERSUS JSON:  WebFinger specifies both XML and JSON support,
> whereas SWD specifies only JSON.  The SWD position is 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.
>

Webfinger only used XRD in the first place to satisfy the OpenID community.
This is infuriating format-fetishism, and misses the point entirely. JSON
is preferred, and I, for one, would happily modify host-meta and webfinger
to require JSON is people feel this strongly about it.

> 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, the "acct" Link Relation.
>  These should be considered on their own merits, but logically should be
> decoupled from the discovery protocol into a different document or
> documents.  It's not clear these features would be needed in OAuth contexts.
>

I have long argued against the acct URI, but the consensus-based approach
of the IETF has over-ridden me on that one. If you feel similarly, you are
free to voice that opinion.

It shocks me that you're saying that the OAuth WG shouldn't consider
host-meta/webfinger because it defines something that isn't of interest to
the OAuth WG. The whole point of my argument at the WG meeting in Paris was
that Webfinger and SWD-like protocols are of such consequence to the web at
large that the interests of the OAuth WG should not be used to define the
parameters for their behaviour.

I'm more convinced that you're using your power within this WG to have SWD
rubber-stamped so that you can ship OpenID Connect as you've defined it.

>                They are solving an overlapping set of problems, but with
> very different privacy characteristics, different deployability
> characteristics, different security characteristics, and somewhat different
> mechanisms.
>

Again, I totally disagree with your assessment here, Mike.

> cases (and likely for others as well).

I agree with this – since SWD is an explicit (though unstated) fork of
Webfinger, there is no need to have two standards.

>                The functionality in Simple Web Discovery is minimal and
> sufficient for the OAuth use cases, whereas some of the functionality and
> assumptions made in WebFinger are harmful, both from a privacy and from a
> deployability perspective.  SWD should proceed to standardization;
> WebFinger should not.

I believe Mike has made misleading statements regarding the privacy and
deployability perspective, either intentionally, or because he
fundamentally does not understand the security or deployment scenarios that
motivate the decisions.

In summary:

1. I believe that SWD and Webfinger are essentially the same protocol, with
different authors names at the top.
2. I don't care which one "wins", though I think that SWD's use of HTTP is
questionable, and that the claims of privacy and deployability advantages
offered by SWD are overblown and potentially misleading.
3. My concerns about SWD apply equally to any concerns anyone would
leverage against Webfinger.
4. Which is to say, I think we should have one protocol that is defined by
an open discussion.
5. We've had an open discussion on the webfinger list and apps-discuss and
in the context of host-meta that the SWD folks have chosen not to engage
with for the past three years.
6. The OAuth list is *not* the place for this discussion to happen, just so
that Mike Jones can quickly push a spec through the formal process using a
list that has well-known problems of too-high mail volume and whose topic
is unrelated to the goals of Webfinger/SWD.

This is important enough to get right, and getting it wrong will almost
certainly lead to years of incompatibility and frustration, as Stephen
mentioned. I encourage everyone involved to take this seriously, let go of
personal attachment and presumptions of dependencies, and consider this
work in an appropriate context (with an inclusive, not exclusive community).

b.

---

From: Mike Jones <[email-masked]>
Date: Fri, 13 Apr 2012 16:18:02 +0000

Hi Blaine.  I must admit, I’m pretty surprised by the tone of your reply.  I’ll say up front that I have absolutely no problem with anyone disagreeing with me on a technical or tactical basis.  If you think I’m wrong, have at it.

But I am pretty shocked that you would decide to impugn my motives.  We’ve only met twice and both times I thought we had really useful and productive discussions about how to move digital identity on the Web forward – something I believe that we’re both passionate about.  You don’t really know me, though, which is apparent from your remarks below.  I believe that those who have worked with me for years would vouch that I am a forthright and evenhanded standards participant who listens to all points of view, tries to build a consensus that works, and produce quality results.

I thought about your note overnight and whether I should reply at all.  I’m fine with give and take, but I believe that I need to say that if you read what you wrote below, I think you’ll agree that the tone you used was counter-productive and an apology is in order.

                                                            -- Mike

P.S.  I’ll address your technical points below in a separate note at some point – some I agree with and some I don’t.  But I felt that I needed to address my motives being questioned separately and first.  I hope we can both come out of this with a better understanding of one another and work together towards the important goals that we both share.

From: Blaine Cook [mailto:[email-masked]]
Sent: Thursday, April 12, 2012 3:41 PM
To: Mike Jones
Cc: Hannes Tschofenig; [email-masked] WG
Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

On 12 April 2012 17:51, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for asking these questions Hannes.  I'll first provide a brief feature comparison of Simple Web Discovery and WebFinger and then answer your questions.

FEATURE COMPARISON

SWD provides no privacy whatsoever. SWD makes it somewhat harder to crawl large numbers of profiles, but it does not incorporate any real security, and any attempt to suggest that it does is misleading and deceptive.

Webfinger, like any good HTTP service, is designed to allow access control using appropriate means. That access control should not be *bound* to the protocol, in the same way that HTTP does not have any REQUIRED access control mechanisms, since doing so would severely restrict future usage of a core protocol.

FUD has no place in a discussion of the technical and social merits of a protocol.

For what it's worth, my intent with webfinger *from day one, nearly four years ago*, has been to provide permissioned profile data *using EXISTING* (or new, where appropriate or necessary, based on *running code and deployment EXPERIENCE*) access control mechanisms for profile data.

The idea that there is ONE view of the data is patently false. For example, depending on who is requesting my profile data, I might return different contact telephone numbers, and this behaviour is completely feasible using webfinger.

APIs and documents on the web are the same thing; how you represent them behind the scenes is up to you, and that's been a core principle of the web since shortly after its inception. Suggesting otherwise profoundly misunderstands how implementation of web services happens.

SWD says nothing of how to update profile data, so the security concerns here are a total red herring.

Umm, I'm not even sure what to say to this. host-meta is a static file that points to a profile server (generally expected to be a dynamic "API" server) that can be hosted on any domain.

The fact that you're suggesting that this core piece of webfinger functionality is *missing* seriously undermines my belief that you're acting in good faith, Mike.

... at the cost of greater client complexity. A webfinger lookup may be implemented with the following trivial shell script:

curl -s http://example.com/.well-known/host-meta|awk "/lrdd/,/template/"|tr -d '\n'|sed -e "s/^.*template='\([^']*\)'.*$/\1/"|sed -e "s/{uri}/[email-masked]/<http://[email-masked]/>"|xargs curl -s

so long as your HTTP client properly follows redirects, this approach will always produce a valid webfinger profile, and if proper caching is implemented, will only make requests to /.well-known/host-meta when the document is expired.

SWD, on the other hand, implements a non-HTTP redirect mechanism, meaning that optimal caching rules can't be obeyed by standard HTTP clients. Moreover, SWD *requires* conditionals by presenting one code path for the non-redirect case and one code path for the immediate response case.

The complexity for client implementations should be foremost in this work, and the decisions made by SWD don't indicate to me that these factors have been considered.

Indeed, I wonder why is SWD designed to pre-optimize for presumed scaling challenges that are faced by only the very largest providers (namely, the fact that two lookups are required for webfinger instead of one in the ideal case), when:

1. Those scaling challenges are simply not real threats. host-meta can be cached using existing HTTP mechanisms
2. The fact that SWD only returns one service definition per request means that more than one request will often be required to obtain the necessary information about a user.
3. The chances that Google or Microsoft will host dynamic response SWD services on the gmail.com<http://gmail.com> or hotmail.com<http://hotmail.com> domains is next to nil, and will therefore need to issue redirects anyways.

For smaller providers (e.g., personal domains hosted in static or rigid environments), hosting a SWD server at /.well-known/simple-web-discovery may be challenging indeed. Thus, all clients will need to support the redirect behaviour natively, and for those who write specs but not code, it is *more* complex to have conditional behaviour like that than to have a defined flow that is always followed.

Further, it's more complex for small service providers to host static content that is invariant and properly cached (e.g., by transparent proxy caches like varnish and squid) when CGI parameters are appended, as with SWD.

Webfinger only used XRD in the first place to satisfy the OpenID community. This is infuriating format-fetishism, and misses the point entirely. JSON is preferred, and I, for one, would happily modify host-meta and webfinger to require JSON is people feel this strongly about it.

I have long argued against the acct URI, but the consensus-based approach of the IETF has over-ridden me on that one. If you feel similarly, you are free to voice that opinion.

It shocks me that you're saying that the OAuth WG shouldn't consider host-meta/webfinger because it defines something that isn't of interest to the OAuth WG. The whole point of my argument at the WG meeting in Paris was that Webfinger and SWD-like protocols are of such consequence to the web at large that the interests of the OAuth WG should not be used to define the parameters for their behaviour.

I'm more convinced that you're using your power within this WG to have SWD rubber-stamped so that you can ship OpenID Connect as you've defined it.

QUESTIONS

I agree with this – since SWD is an explicit (though unstated) fork of Webfinger, there is no need to have two standards.

I believe Mike has made misleading statements regarding the privacy and deployability perspective, either intentionally, or because he fundamentally does not understand the security or deployment scenarios that motivate the decisions.

In summary:

1. I believe that SWD and Webfinger are essentially the same protocol, with different authors names at the top.
2. I don't care which one "wins", though I think that SWD's use of HTTP is questionable, and that the claims of privacy and deployability advantages offered by SWD are overblown and potentially misleading.
3. My concerns about SWD apply equally to any concerns anyone would leverage against Webfinger.
4. Which is to say, I think we should have one protocol that is defined by an open discussion.
5. We've had an open discussion on the webfinger list and apps-discuss and in the context of host-meta that the SWD folks have chosen not to engage with for the past three years.
6. The OAuth list is *not* the place for this discussion to happen, just so that Mike Jones can quickly push a spec through the formal process using a list that has well-known problems of too-high mail volume and whose topic is unrelated to the goals of Webfinger/SWD.

This is important enough to get right, and getting it wrong will almost certainly lead to years of incompatibility and frustration, as Stephen mentioned. I encourage everyone involved to take this seriously, let go of personal attachment and presumptions of dependencies, and consider this work in an appropriate context (with an inclusive, not exclusive community).

b.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Apr 2012 17:22:40 +0100

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.

---

From: Melvin Carvalho <[email-masked]>
Date: Fri, 13 Apr 2012 18:31:01 +0200

On 12 April 2012 13:00, Hannes Tschofenig <[email-masked]> 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.

No mention of Linked Data?  (eg JSON LD).  Even tho it's used to discover
data by most governments, the world bank, over 2000 retailers, all major
search engines?

Webfinger I love the concept, but seems overly complicated to me.
Introduction of the acct: scheme seems unnecessary.  No where in the spec
does it cover how to get from mailto:user@host -> acct:user@host which, if
im not mistaken, seems to defeat the object of the forward lookup.  From a
practical perspective it seems both xml and json must be supported which is
an added layer of complexity.

Also note that discovery is an additive process... in a certain way, you
could say, the more the better :)

>
> 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."
>
>
>
>

---

From: William Mills <[email-masked]>
Date: Fri, 13 Apr 2012 10:15:44 -0700 (PDT)

Or perhaps update/extend the existing spec to do what is needed?  Is there anything that is fundamentally in conflict?

-bill

>________________________________
> From: Igor Faynberg <[email-masked]>
>To: John Bradley <[email-masked]> 
>Cc: [email-masked] 
>Sent: Thursday, April 12, 2012 11:29 AM

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 13 Apr 2012 17:45:32 +0000

> 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)
> 
> 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:-
> 

Thank you Stephen, I think.  :-)

So the discussion on apps-discuss now should be focused on which of the two should be the basis for forward progress.  I've placed both documents in "Call for Adoption" state in the datatracker for appsawg.

Let the games begin.

-MSK

---

From: Blaine Cook <[email-masked]>
Date: Fri, 13 Apr 2012 18:47:12 -0400

On 13 April 2012 12:18, Mike Jones <[email-masked]> wrote:

>  Hi Blaine.  I must admit, I’m pretty surprised by the tone of your
> reply.  I’ll say up front that I have absolutely no problem with anyone
> disagreeing with me on a technical or tactical basis.  If you think I’m
> wrong, have at it.****
>
> ** **
>
> But I am pretty shocked that you would decide to impugn my motives.  We’ve
> only met twice and both times I thought we had really useful and productive
> discussions about how to move digital identity on the Web forward –
> something I believe that we’re both passionate about.  You don’t really
> know me, though, which is apparent from your remarks below.  I believe that
> those who have worked with me for years would vouch that I am a forthright
> and evenhanded standards participant who listens to all points of view,
> tries to build a consensus that works, and produce quality results.
>

>
> I thought about your note overnight and whether I should reply at all.
> I’m fine with give and take, but I believe that I need to say that if you
> read what you wrote below, I think you’ll agree that the tone you used was
> counter-productive and an apology is in order.
>

I'm sorry for any offensive comments or tone on my part. I was really taken
aback by your comments, because we have had those conversations about
Webfinger/SWD, and your technical commentary seemed to me to attempt to
intentionally undermine webfinger in ways that I couldn't fathom, given the
things we've previously discussed in person.

I look forward to moving ahead with future discussions on SWD/Webfinger
(frankly, SWD is a better name. ;-) ) in the apps area, and hope that my
irate tone hasn't caused any permanent rift. I think we both agree that
this work is incredibly important for the future of the web, and I'm
hopeful that we can build the best mechanism to provide that future.

Best,

b.

---

From: Mike Jones <[email-masked]>
Date: Fri, 13 Apr 2012 22:58:31 +0000

Thanks Blaine.  I appreciate it, and I’m sorry for any misstatements in my note.  Yes, we both agree on how important this and I look forward to working with you to make it happen!

                                                                Best wishes,
                                                                -- Mike

From: Blaine Cook [mailto:[email-masked]]
Sent: Friday, April 13, 2012 3:47 PM
To: Mike Jones
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

On 13 April 2012 12:18, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Hi Blaine.  I must admit, I’m pretty surprised by the tone of your reply.  I’ll say up front that I have absolutely no problem with anyone disagreeing with me on a technical or tactical basis.  If you think I’m wrong, have at it.

I'm sorry for any offensive comments or tone on my part. I was really taken aback by your comments, because we have had those conversations about Webfinger/SWD, and your technical commentary seemed to me to attempt to intentionally undermine webfinger in ways that I couldn't fathom, given the things we've previously discussed in person.

I look forward to moving ahead with future discussions on SWD/Webfinger (frankly, SWD is a better name. ;-) ) in the apps area, and hope that my irate tone hasn't caused any permanent rift. I think we both agree that this work is incredibly important for the future of the web, and I'm hopeful that we can build the best mechanism to provide that future.

Best,

b.

---

From: Eran Hammer <[email-masked]>
Date: Sun, 15 Apr 2012 06:21:23 +0000

Tone aside, this is not the first time you distorted process and technical facts to suit your goals. Just look up some of our exchanges from a year ago and the transcript of the Prague meeting for highlights.

EH

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, April 13, 2012 9:18 AM
To: Blaine Cook
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

                                                            -- Mike

From: Blaine Cook [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Thursday, April 12, 2012 3:41 PM
To: Mike Jones
Cc: Hannes Tschofenig; [email-masked]<mailto:[email-masked]> WG
Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

FEATURE COMPARISON

QUESTIONS

In summary:

b.

---

From: Melvin Carvalho <[email-masked]>
Date: Sun, 15 Apr 2012 10:56:05 +0200

On 15 April 2012 08:21, Eran Hammer <[email-masked]> wrote:

>  Tone aside, this is not the first time you distorted process and
> technical facts to suit your goals. Just look up some of our exchanges from
> a year ago and the transcript of the Prague meeting for highlights.
>

As stephen suggests, could we possibly continue this fascinating discussion
on apps discuss?

I know people are passionate about this issue, and that's a positive
thing.

But I think it probably would be most productive, if we could all try to
keep personal attacks to a minimum.

> ****
>
> ** **
>
> EH****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Mike Jones
> *Sent:* Friday, April 13, 2012 9:18 AM
> *To:* Blaine Cook
> *Cc:* [email-masked] WG
>
> *Subject:* Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)****
>
>  ** **
>
> Hi Blaine.  I must admit, I’m pretty surprised by the tone of your reply.
> I’ll say up front that I have absolutely no problem with anyone disagreeing
> with me on a technical or tactical basis.  If you think I’m wrong, have at
> it.****
>
> ** **
>
> tries to build a consensus that works, and produce quality results.****
>
> ** **
>
> counter-productive and an apology is in order.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> P.S.  I’ll address your technical points below in a separate note at some
> point – some I agree with and some I don’t.  But I felt that I needed to
> address my motives being questioned separately and first.  I hope we can
> both come out of this with a better understanding of one another and work
> together towards the important goals that we both share.****
>
> ** **
>
> *From:* Blaine Cook [mailto:[email-masked]]
> *Sent:* Thursday, April 12, 2012 3:41 PM
> *To:* Mike Jones
> *Cc:* Hannes Tschofenig; [email-masked] WG
> *Subject:* Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)****
>
> ** **
>
> On 12 April 2012 17:51, Mike Jones <[email-masked]> wrote:***
> *
>
> preferable.****
> This is absolutely false.****
>
> ** **
>
> and any attempt to suggest that it does is misleading and deceptive.****
>
> ** **
>
> a core protocol.****
> protocol.****
> deployment EXPERIENCE*) access control mechanisms for profile data.****
>
> ** **
>
> The idea that there is ONE view of the data is patently false. For
> example, depending on who is requesting my profile data, I might return
> different contact telephone numbers, and this behaviour is completely
> feasible using webfinger.****
>
>  ****
>
> to change your mail server.)****
>
>  ** **
>
> WS-* was built on an API model, and that worked out very well.****
>
> ** **
>
> misunderstands how implementation of web services happens.****
>
> ** **
>
> here are a total red herring.****
>
>  ****
>
> environments, this functionality seems pretty important.****
>
>  ** **
>
> Umm, I'm not even sure what to say to this. host-meta is a static file
> that points to a profile server (generally expected to be a dynamic "API"
> server) that can be hosted on any domain.****
>
> ** **
>
> acting in good faith, Mike.****
>
>  ****
>
> achieved in a single SWD query.****
>
>  ** **
>
> implemented with the following trivial shell script:****
>
> ** **
>
> curl -s http://example.com/.well-known/host-meta|awk"/lrdd/,/template/"|tr -d '\n'|sed -e
> "s/^.*template='\([^']*\)'.*$/\1/"|sed -e "s/{uri}/[email-masked]/"|xargs
> curl -s****
>
>  ****
>
> document is expired.****
> non-redirect case and one code path for the immediate response case.****
>
> ** **
>
> been considered.****
> ideal case), when:****
> cached using existing HTTP mechanisms****
>
> information about a user.****
>
> therefore need to issue redirects anyways.****
>
> ** **
>
> defined flow that is always followed.****
>
> ** **
>
> SWD.****
> made for the OAuth specs.****
>
>  ** **
>
> Webfinger only used XRD in the first place to satisfy the OpenID
> community. This is infuriating format-fetishism, and misses the point
> entirely. JSON is preferred, and I, for one, would happily modify host-meta
> and webfinger to require JSON is people feel this strongly about it.****
>
>  ****
>
> ****
> free to voice that opinion.****
>
> ** **
>
> parameters for their behaviour.****
>
> ** **
>
> rubber-stamped so that you can ship OpenID Connect as you've defined it.**
> **
>
>  ****
>
> QUESTIONS****
>
>
> 1) Aren't these two mechanisms solving pretty much the same problem?****
>
> mechanisms.****
> Again, I totally disagree with your assessment here, Mike.****
>
>  ****
>
>  2) Do we need to have two standards for the same functionality?****
>
>               No - Simple Web Discovery is sufficient for the OAuth use
> cases (and likely for others as well).****
>
>  ** **
>
> Webfinger, there is no need to have two standards.****
>
>  ****
>
>  3) Do you guys have a position or comments regarding either one of them?*
> ***
>
> WebFinger should not.****
>
>  ** **
>
> motivate the decisions.****
>
> ** **
>
> In summary:****
>
> ** **
>
> 1. I believe that SWD and Webfinger are essentially the same protocol,
> with different authors names at the top.****
>
> offered by SWD are overblown and potentially misleading.****
>
> leverage against Webfinger.****
>
> an open discussion.****
> with for the past three years.****
>
> 6. The OAuth list is *not* the place for this discussion to happen, just
> so that Mike Jones can quickly push a spec through the formal process using
> a list that has well-known problems of too-high mail volume and whose topic
> is unrelated to the goals of Webfinger/SWD.****
>
> ** **
>
> ****
> b.****

---

From: John Bradley <[email-masked]>
Date: Sun, 15 Apr 2012 11:16:41 +0200

I look forward to working with Blaine, Mike and others interested on the apps list.

I anticipate being able to find a way forward.

Regards
John B.

On 2012-04-15, at 10:56 AM, Melvin Carvalho wrote:

> As stephen suggests, could we possibly continue this fascinating discussion on apps discuss?  
> 
> I know people are passionate about this issue, and that's a positive thing.  
> 
> But I think it probably would be most productive, if we could all try to keep personal attacks to a minimum.
>  
> 
>  
> 
> EH
> 
>  
> 
>  
> 
>  
> 
> curl -s http://example.com/.well-known/host-meta|awk "/lrdd/,/template/"|tr -d '\n'|sed -e "s/^.*template='\([^']*\)'.*$/\1/"|sed -e "s/{uri}/[email-masked]/"|xargs curl -s
> 
>  
> 
> 3. The chances that Google or Microsoft will host dynamic response SWD services on the gmail.com or hotmail.com domains is next to nil, and will therefore need to issue redirects anyways.
> 
>  
>

---

From: Pelle Wessman <[email-masked]>
Date: Sun, 15 Apr 2012 17:11:52 +0200

Could someone please explain to me how Webfinger solves the same problem as
SWD?

Isn't Webfinger just defining a way to discover data about a user using the
"Web Host Metadata" discovery mechanism that's already defined in RFC 6415?
While SWD instead defines an entirely new discovery mechanism without
really defining how to use it to discover data about a user?

To me it seems like SWD instead solves the same problem as RFC 6415? What
am I missing?

I personally still prefer the original Webfinger proposal that didn't
really define anything extra but just showed how to use RFC 6415 to
discover data about users. The way it worked made it, as I see it, easy to
expose your data and to consume it. I don't really see a point in the
recent additions to the Webfinger draft - anything beyond specifying the
acct URL scheme and a few basic link relations seems unneeded and out of
scope to me and just complicates things.

/ Pelle Wessman

---

From: Derek Atkins <[email-masked]>
Date: Mon, 16 Apr 2012 15:07:08 -0400

>From an OAUTH perspective I believe that we should help define the
requirements of what this protocol needs to provide (be it webfinger,
swd, or yadp (Yet Another Discovery Protocol) -- whatever it's named!)

I think there are two main differerences between webfinger and swd:

a) whole-document vs. individual attributes
b) a perceived authorization model to control access to said attributes

In particular I feel there are some specific security requirements that
must be bet by the protocol, but I think it's easily accomplished by
a small amount of text that effectively says:

1) requestors of the service should authenticate (or be treated as an
   anonymous user)
2) content returned must be dynamic and dependent on the authorization
   of the authenticated user.

This leaves only the perceived issue of "whole document" vs "individual
attribute".  If a client ever wants more than one attribute then a whole
document approach reduces the number of round trips.  However if
documents get large that could also affect performance.  We might, then,
need a way to specify which attributes are requested, but allow for a
wildcard to return "everything I am authorized to see".

> Let the games begin.

Heh.  Play ball!

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Kevin Marks <[email-masked]>
Date: Mon, 16 Apr 2012 12:47:48 -0700

>   of the authenticated user.

I think requesters MAY authenticate, not SHOULD.

> wildcard to return "everything I am authorized to see".

Something like the PoCo query model?

---

From: Tim Bray <[email-masked]>
Date: Mon, 16 Apr 2012 15:33:00 -0700

What is the deployment status of these two specs?  Is either deployed
much at all?  -T

On Fri, Apr 13, 2012 at 10:45 AM, Murray S. Kucherawy <[email-masked]> wrote:
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Blaine Cook <[email-masked]>
Date: Tue, 17 Apr 2012 18:54:16 -0400

That's a tricky question - maybe one google can help answer? There are a
bunch of projects using webfinger, including status.net, ostatus in
general, diaspora, unhosted, freedombox(?), and I'm sure others, but I have
no idea how that translates into actual users or profiles.

Gmail, aol, and yahoo all put up webfinger endpoints, but there hasn't been
much movement, I think due to the chicken and egg nature of adoption around
decentralized tools.

b.
On Apr 17, 2012 11:13 AM, "Tim Bray" <[email-masked]> wrote:

> >> From: [email-masked] [mailto:
> [email-masked]] On Behalf Of Stephen Farrell
> > So the discussion on apps-discuss now should be focused on which of the
> two should be the basis for forward progress.  I've placed both documents
> in "Call for Adoption" state in the datatracker for appsawg.
> >
> > Let the games begin.
> >
> > -MSK

---

From: Mike Jones <[email-masked]>
Date: Tue, 17 Apr 2012 23:24:46 +0000

I know that 7 of the 8 public participants in the current OpenID Connect interop testing have implemented SWD at this point.  (I know of several more who’ve built it as well but haven’t chosen to make their interop test results public yet.)  There are likely other implementations I’m unaware of.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Blaine Cook
Sent: Tuesday, April 17, 2012 3:54 PM
To: Tim Bray
Cc: [email-masked] WG; [email-masked]
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)

That's a tricky question - maybe one google can help answer? There are a bunch of projects using webfinger, including status.net<http://status.net>, ostatus in general, diaspora, unhosted, freedombox(?), and I'm sure others, but I have no idea how that translates into actual users or profiles.

Gmail, aol, and yahoo all put up webfinger endpoints, but there hasn't been much movement, I think due to the chicken and egg nature of adoption around decentralized tools.

b.
On Apr 17, 2012 11:13 AM, "Tim Bray" <[email-masked]<mailto:[email-masked]>> wrote:
What is the deployment status of these two specs?  Is either deployed
much at all?  -T

On Fri, Apr 13, 2012 at 10:45 AM, Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>> wrote:
>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Stephen Farrell
>> To: [email-masked]<mailto:[email-masked]> WG
>> Cc: Apps Discuss
> [email-masked]<mailto:[email-masked]>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Apr 2012 02:54:37 +0000

So there are some of both.  How treacherous is the migration path from SWD to WebFinger, for example, in case consensus is to develop and move forward with the latter?

-MSK

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Tuesday, April 17, 2012 4:25 PM
To: Blaine Cook; Tim Bray
Cc: [email-masked] WG; [email-masked]
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Blaine Cook
Sent: Tuesday, April 17, 2012 3:54 PM
To: Tim Bray
Cc: [email-masked]<mailto:[email-masked]> WG; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)

b.

---

From: Dick Hardt <[email-masked]>
Date: Thu, 19 Apr 2012 08:52:13 -0700

A couple months ago I was checking out what was up. The AOL and Yahoo endpoints no longer worked. The Google one still did.

On Apr 17, 2012, at 3:54 PM, Blaine Cook wrote:

> That's a tricky question - maybe one google can help answer? There are a bunch of projects using webfinger, including status.net, ostatus in general, diaspora, unhosted, freedombox(?), and I'm sure others, but I have no idea how that translates into actual users or profiles.
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Apr 2012 16:32:06 +0000

By all means people should correct me if they think I'm wrong about this, but so far from monitoring the discussion there seems to be general support for focusing on WebFinger and developing it to meet the needs of those who have deployed SWD, versus the opposite.

Does anyone want to argue the opposite?

-MSK, appsawg co-chair

---

From: William Mills <[email-masked]>
Date: Thu, 19 Apr 2012 09:41:05 -0700 (PDT)

I would characterize it as two distinct camps, folks that think WF can be updated to do what SWD (growing contingent I think) does and folks that are invested in SWD.  I haven't seen any movement between those two camps, specifically that the SWD folks think WF can in fact solve their problem if updated.

-bill

> From: Murray S. Kucherawy <[email-masked]>
>To: "[email-masked] WG" <[email-masked]>; Apps Discuss <[email-masked]> 
>Sent: Thursday, April 19, 2012 9:32 AM

---

From: Mike Jones <[email-masked]>
Date: Thu, 19 Apr 2012 16:48:45 +0000

There are two criteria that I would consider to be essential requirements for any resulting general-purpose discovery specification:

1.  Being able to always discover per-user information with a single GET (minimizing user interface latency for mobile devices, etc.)

2.  JSON should be required and it should be the only format required (simplicity and ease of deployment/adoption)

SWD already meets those requirements.  If the resulting spec meets those requirements, it doesn't matter a lot whether we call it WebFinger or Simple Web Discovery, but I believe that the requirements discussion is probably the most productive one to be having at this point - not the starting point document.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Thursday, April 19, 2012 9:32 AM
To: [email-masked] WG; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

-MSK, appsawg co-chair

---

From: Melvin Carvalho <[email-masked]>
Date: Thu, 19 Apr 2012 18:54:01 +0200

On 19 April 2012 18:48, Mike Jones <[email-masked]> wrote:

> There are two criteria that I would consider to be essential requirements
> for any resulting general-purpose discovery specification:
>
> 1.  Being able to always discover per-user information with a single GET
> (minimizing user interface latency for mobile devices, etc.)
>
> 2.  JSON should be required and it should be the only format required
> (simplicity and ease of deployment/adoption)
>
> SWD already meets those requirements.  If the resulting spec meets those
> requirements, it doesn't matter a lot whether we call it WebFinger or
> Simple Web Discovery, but I believe that the requirements discussion is
> probably the most productive one to be having at this point - not the
> starting point document.
>

+1

                               -- Mike
> By all means people should correct me if they think I'm wrong about this,
> but so far from monitoring the discussion there seems to be general support
> for focusing on WebFinger and developing it to meet the needs of those who
> have deployed SWD, versus the opposite.
>

---

From: John Panzer <[email-masked]>
Date: Thu, 19 Apr 2012 09:57:15 -0700

> (minimizing user interface latency for mobile devices, etc.)

Clarification:  Does this requirement still allow HTTP redirects?  (Meaning
the server is in control of whether there is a single GET or not,
basically, but can always ensure a single GET to minimize latency.)

> (simplicity and ease of deployment/adoption)
I think nobody would argue against JSON support (certainly not me), I think
few would argue against making it required.  I personally would be okay
with actually standardizing on JSON as the only required format as it
doesn't preclude anyone from supporting other formats if they wish (for
legacy/etc. reasons).

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Apr 2012 17:02:20 +0000

Fair enough, carry on.  :)

From: Melvin Carvalho [mailto:[email-masked]]
Sent: Thursday, April 19, 2012 9:54 AM
To: Mike Jones
Cc: Murray S. Kucherawy; [email-masked] WG; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

On 19 April 2012 18:48, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
There are two criteria that I would consider to be essential requirements for any resulting general-purpose discovery specification:

+1
                               -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Murray S. Kucherawy
Sent: Thursday, April 19, 2012 9:32 AM
To: [email-masked]<mailto:[email-masked]> WG; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

-MSK, appsawg co-chair

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 19 Apr 2012 14:02:48 -0400

+1 on the requirements.

---

From: Mike Jones <[email-masked]>
Date: Thu, 19 Apr 2012 18:22:46 +0000

I agree that redirects need to be followed, when used.

-- Mike
From: John Panzer
Sent: 4/19/2012 7:04 PM

On Thu, Apr 19, 2012 at 9:48 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
There are two criteria that I would consider to be essential requirements for any resulting general-purpose discovery specification:

Clarification:  Does this requirement still allow HTTP redirects?  (Meaning the server is in control of whether there is a single GET or not, basically, but can always ensure a single GET to minimize latency.)

I think nobody would argue against JSON support (certainly not me), I think few would argue against making it required.  I personally would be okay with actually standardizing on JSON as the only required format as it doesn't preclude anyone from supporting other formats if they wish (for legacy/etc. reasons).

                               -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Murray S. Kucherawy
Sent: Thursday, April 19, 2012 9:32 AM
To: [email-masked]<mailto:[email-masked]> WG; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

-MSK, appsawg co-chair

---

From: Eran Hammer <[email-masked]>
Date: Thu, 19 Apr 2012 18:26:34 +0000

#1 as John Panzer identified, allowing the server to control its deployment and supporting HTTP redirects is critical.
#2 JSON is better, which one is required is less of on issue but more of a best practices item.

I'll add:

* Highly cachable
* Optimize for large providers, reducing the need to make repeated requests when the information is mostly following a template on the server side
* Ability to provide discovery on resources, not users or any other subset (emails, etc.)
* Security agnostic - leave it to HTTP, TLS, OAuth, etc.
* HTTP compliant - doesn't invent it's own rediretion menthods or custom headers, etc.

EH

> Sent: Thursday, April 19, 2012 9:49 AM
> To: Murray S. Kucherawy; [email-masked] WG; Apps Discuss
> There are two criteria that I would consider to be essential requirements for
> any resulting general-purpose discovery specification:
> 
> requirements, it doesn't matter a lot whether we call it WebFinger or Simple
> Web Discovery, but I believe that the requirements discussion is probably
> the most productive one to be having at this point - not the starting point
> document.
> 
> 				-- Mike
> 
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Murray S. Kucherawy
> By all means people should correct me if they think I'm wrong about this, but
> so far from monitoring the discussion there seems to be general support for
> focusing on WebFinger and developing it to meet the needs of those who

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 19 Apr 2012 20:40:06 +0200

Hi Mike,

> 1.  Being able to always discover per-user information with a single GET (minimizing user interface latency for mobile devices, etc.)

Is this a requirement from an OpenID Connect perspective? I'm asking 
because I think a user is not always the starting point of a discovery 
process in the more general OAuth case. In my opinion there is a need to 
discover
(1) the authorization server a particular resource server relies on 
("www.example.com/webdav" --> "as.example.com" and
(2) the properties of this authz server ("as.example.com" --> tokens, 
authz, revocation endpoints, grant types, ...).

How would this work with SWD or WebFinger?

regards,
Torsten.

---

From: Melvin Carvalho <[email-masked]>
Date: Thu, 19 Apr 2012 23:12:23 +0200

On 19 April 2012 20:26, Eran Hammer <[email-masked]> wrote:

> #1 as John Panzer identified, allowing the server to control its
> deployment and supporting HTTP redirects is critical.
>

+1

> #2 JSON is better, which one is required is less of on issue but more of a

Happy with this comment, and a +1 for JSON only

> * Highly cachable

+1 tho I think most CSN dont cache a 303 redirect

> * Optimize for large providers, reducing the need to make repeated
> requests when the information is mostly following a template on the server
> side
>

+1

> * Ability to provide discovery on resources, not users or any other subset

There's a subtlety here and that's the difference in HTML between "rel" and
"rev".

A forward or reverse lookup.  Forward is a natural way to look things up,
eg you give a URL and you get a document.  But something like google search
is actually a reverse index, you give it words and you get back URLs for
documents.  Initially hard to get your head round, but in practice can be
incredibly practical and useful.

Given a triple such as (subject verb object)

<acct:user@host>  email  <mailto:user@host>

Is your lookup based on the subject (WF) or the object (SWF)?

If subject then you need something there.  However, it need not be an acct:
URI

It could be a URN eg

urn:acct:user@host  (no new uri scheme needed)

it could be a relative URI such as

<#>  (which facebook do)

This indicates a pointer to the top of the document

It can even be blank

<>

The so-called 'blank node' in the linked data world, but then you're more
reliant on a query language, such as SPARQL.

I'm sure I havent covered every possibility.

OR you can key off the Object

<anything>  email <mailto:user@host>

then return all key values assoicated with <anything> which would be in the
@subject position in the case of XRD/JRD or the @id position in the case of
something like JSON LD

It's quite confusing but essentially you are asking two very different
things:

1) Give me all information where the subject is acct:user@host

Which also means having to create a mapping, and educating every system
what the subject of their email (or xmpp/sip/tel/twitter account) should
be.  A potentially big task.  Im not saying it's wrong, but IMHO this is
potentially big enough to fill a whole other standards document in itself.

or

2) Give me all information for the user with email mailto:user@host

Non disruptive

I'm sorry If i have not explained this very well, but the difference
between rev and rel confuses a lot of confusion in HTML, and that's
essentially the subtlety here (forward vs reverse lookup)

+1

+1

> Simple

---

From: Melvin Carvalho <[email-masked]>
Date: Thu, 19 Apr 2012 23:13:18 +0200

> +1 tho I think most CSN dont cache a 303 redirect

Apologies CSN should read CDN

> There's a subtlety here and that's the difference in HTML between "rel"
> and "rev".
>
> If subject then you need something there.  However, it need not be an
> acct: URI
>
> It could be a URN eg
>
> then return all key values assoicated with <anything> which would be in
> the @subject position in the case of XRD/JRD or the @id position in the
> case of something like JSON LD
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 19 Apr 2012 23:15:45 -0400

Mike,

> (minimizing user interface latency for mobile devices, etc.)

WF can do that.  See:
$ curl -v https://packetizer.com/.well-known/\
          host-meta.json?resource=acct:[email-masked]
 
> (simplicity and ease of deployment/adoption)

See the above example.  However, I also support XML with my server.  It took
me less than 10 minutes to code up both XML and JSON representations.  Once
the requested format is determined, the requested URI is determined, data is
pulled from the database, spitting out the desired format is trivial.
 
Note, and very important note: supporting both XML and JSON would only be a
server-side requirement.  The client is at liberty to use the format it
prefers.  I would agree that forcing a client to support both would be
unacceptable, but the server?  Nothing to it.
 
> probably the most productive one to be having at this point - not the

I believe WebFinger meets those requirements.  We could debate whether XML
should be supported, but I'll note (again) that it is there in RFC 6415.
That document isn't all that old and, frankly, it concerns me that we would
have a strong preference for format A one week and then Format B the next.
We are where we are and I can see reason for asking for JSON, but no good
reason to say we should not allow XML (on the server side).

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 20 Apr 2012 00:43:08 -0400

Tim,

I do not agree that it's harmful. If I removed the WF discussion off the
table, I'm still having a hard time buying into everything you said in the
blog post.

I implement various web services, largely for my own use.  Usually, I
implement all of them in XML, JSON, plain text (attribute/value pairs), AND
JavaScript (for JSONP).  For simple services, it's not hard.  I do it
because I sometimes have different wants/desires on the client side.  (For
more complex ones, I use XML.)

For your point (1):
For WebFinger, the format is simple.  The XRD and JRD definitions exist and
are clearly defined.  I think the definitions of each are natural.  It's not
hard to produce both.  

For your point (2):
That's a bias you have against XML, no two ways about it.  I tend to prefer
to run XML through a sax-style parser and pull out what I want.  But, doing
data binding is reasonable if one is dealing with complex data structures.
WebFinger is not so complex that it would need to be done that way, but so
what if developers did?  It's their code.  A lot of web services have been
written that way, so let developers choose.

You conclude with "use JSON".  By that logic, we should send the HTML5 team
back to the drawing board and have then re-write it in JSON.  Oh, HTML is a
document format.  Complex JSON isn't?  I'd argue it is whatever you want to
put in it.

In any case, I'm not going to object if the consensus of the group is to
abandon XML entirely.  I personally do not care which format(s) we use.
What bothers me, though, is that we put a stake in the ground a few years
ago and people were happy until *very* recently.  Now, we want to pull it
out of the ground and put in a whole new one.

Engineering protocols should involve thinking far down the road.  I cannot
fault anyone for having selected XML at the outset.  I cannot fault anyone
for wanting to add JSON support now for something this simple to implement
on the server.  However, what I call dangerous is declaring that JSON should
be the only format for the web, ignoring the significant investment web
developers have in XML.  The motivation for JSON?  Because it works well
with JavaScript, in spite of the fact that nobody would want to do an eval
on it, so it has to be parsed like any other format?  What about the next
web language?  Would we invent a new format for that, too?

This is like throwing out a widely deploy authentication protocol and
re-inventing that wheel, too.  Oh yeah... that would be what was done with
OpenID Connect ;-)

Seriously... is there no sense of maintaining backward compatibility and
rigidly defining protocols for the long-term?

Paul

> From: Tim Bray [mailto:[email-masked]]
> Sent: Thursday, April 19, 2012 11:41 PM
> To: Paul E. Jones
> Cc: Mike Jones; Murray S. Kucherawy; [email-masked]; Apps Discuss
> No. Supporting two different on-the-wire data formats is actively harmful.
> Here are two pieces which explain why:
> 
> - mnot, this month:
> http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide
> - Me, back in 2009
> 
> Pick one. -T
> 
> On Thu, Apr 19, 2012 at 8:15 PM, Paul E. Jones <[email-masked]>
> wrote:
> > Mike,
> >
> >> There are two criteria that I would consider to be essential
> >> requirements for any resulting general-purpose discovery specification:
> >>
> >> 1.  Being able to always discover per-user information with a single
> >> GET (minimizing user interface latency for mobile devices, etc.)
> >
> > WF can do that.  See:
> > See the above example.  However, I also support XML with my server.
> > It took me less than 10 minutes to code up both XML and JSON
> > representations.  Once the requested format is determined, the
> > requested URI is determined, data is pulled from the database, spitting
> out the desired format is trivial.
> >
> > Note, and very important note: supporting both XML and JSON would only
> > be a server-side requirement.  The client is at liberty to use the
> > format it prefers.  I would agree that forcing a client to support
> > both would be unacceptable, but the server?  Nothing to it.
> >
> >> SWD already meets those requirements.  If the resulting spec meets
> >> those requirements, it doesn't matter a lot whether we call it
> >> WebFinger or Simple Web Discovery, but I believe that the
> >> requirements discussion is probably the most productive one to be
> >> having at this point - not the starting point document.
> >
> > I believe WebFinger meets those requirements.  We could debate whether
> > XML should be supported, but I'll note (again) that it is there in RFC
> 6415.
> > That document isn't all that old and, frankly, it concerns me that we
> > would have a strong preference for format A one week and then Format B
> the next.
> > We are where we are and I can see reason for asking for JSON, but no
> > good reason to say we should not allow XML (on the server side).
> >
> > Paul
> >
> >

---

From: Mike Jones <[email-masked]>
Date: Fri, 20 Apr 2012 05:09:48 +0000

Currently, support for the "resource" parameter is optional, as per the following (correct?):

   Note that support for the "resource" parameter is optional, but
   strongly RECOMMENDED for improved performance.  If a server does not
   implement the "resource" parameter, then the server's host metadata
   processing logic remains unchanged from RFC 6415.

To truly support 1, this would need to be changed to REQUIRED, correct?

				-- Mike

-----Original Message-----
From: Paul E. Jones [mailto:[email-masked]] 
Sent: Thursday, April 19, 2012 8:16 PM
To: Mike Jones; 'Murray S. Kucherawy'; [email-masked]; 'Apps Discuss'
Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

Mike,

WF can do that.  See:
 
> (simplicity and ease of deployment/adoption)

See the above example.  However, I also support XML with my server.  It took me less than 10 minutes to code up both XML and JSON representations.  Once the requested format is determined, the requested URI is determined, data is pulled from the database, spitting out the desired format is trivial.
 
Note, and very important note: supporting both XML and JSON would only be a server-side requirement.  The client is at liberty to use the format it prefers.  I would agree that forcing a client to support both would be unacceptable, but the server?  Nothing to it.
 
> WebFinger or Simple Web Discovery, but I believe that the requirements 
> discussion is probably the most productive one to be having at this 
> point - not the starting point document.

I believe WebFinger meets those requirements.  We could debate whether XML should be supported, but I'll note (again) that it is there in RFC 6415.
That document isn't all that old and, frankly, it concerns me that we would have a strong preference for format A one week and then Format B the next.
We are where we are and I can see reason for asking for JSON, but no good reason to say we should not allow XML (on the server side).

Paul

---

From: John Bradley <[email-masked]>
Date: Fri, 20 Apr 2012 07:15:58 +0200

I agree,  requirements are more important than deciding on the starting document at this point. 

I don't care about the name at all.  The proposals are not wolds apart. 

I suspect if we can agree on the requirements for the number of requests most of the other decisions will fall out of that. 

John Bradley

Sent from my iPhone

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 20 Apr 2012 01:38:44 -0400

That's correct.  We could certainly make it mandatory, but the reason it
isn't is to maintain backward compatibility with existing deployments.

I think we should always think carefully when we decide to make a change
that breaks backward-compatibility.  This is one change that would do that.

Paul

> From: Mike Jones [mailto:[email-masked]]
> Sent: Friday, April 20, 2012 1:10 AM
> To: Paul E. Jones; 'Murray S. Kucherawy'; [email-masked]; 'Apps Discuss'
> See the above example.  However, I also support XML with my server.  It
> took me less than 10 minutes to code up both XML and JSON representations.
> Once the requested format is determined, the requested URI is determined,
> data is pulled from the database, spitting out the desired format is
> trivial.
> 
> Note, and very important note: supporting both XML and JSON would only be
> a server-side requirement.  The client is at liberty to use the format it
> would have a strong preference for format A one week and then Format B the
> next.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 20 Apr 2012 01:49:00 -0400

Tim,

I misunderstood.  I thought you authored the MNOT blog post.  That stood in
quite a contrast to your work on XML.  Reading that, I felt like, on a whim,
you threw the baby out with the bathwater and started down a new path,
giving no regard to what exists.

OK, let me reset me mind dizzy head here...

What I do understand is you're suggesting for WF, we should pick one.  It
there was any complexity to it, I'd agree with you.  But, in all
seriousness, producing both XML and JSON for WF is a trivial exercise.  Why
not support both and avoid breaking what exists today?  Asking servers to
add JSON would be easy enough to do.

Paul

> Sent: Friday, April 20, 2012 1:33 AM
> To: Paul E. Jones
> Oops, looks like I left off the link to my own remarks about XML&JSON:
> http://goo.gl/v7Pjr - but they say the same thing, more or less, that MNot
> did.  Your characterizing me as an enemy of XML is amusing, given that my
> name appears at the top of this document: http://goo.gl/lBjkl
> 
> The points 1 & 2 you’re reacting to are from someone else.  But we agree
> that the choice of formats isn’t crucial. Where we disagree is that we
> should pick just one, not multiple ones.  -T
> 
> On Thu, Apr 19, 2012 at 9:43 PM, Paul E. Jones <[email-masked]>
> wrote:
> > Tim,
> >
> > I do not agree that it's harmful. If I removed the WF discussion off
> > the table, I'm still having a hard time buying into everything you
> > said in the blog post.
> >
> > implement all of them in XML, JSON, plain text (attribute/value
> > pairs), AND JavaScript (for JSONP).  For simple services, it's not
> > hard.  I do it because I sometimes have different wants/desires on the
> > client side.  (For more complex ones, I use XML.)
> >
> > For your point (1):
> > For WebFinger, the format is simple.  The XRD and JRD definitions
> > exist and are clearly defined.  I think the definitions of each are
> > natural.  It's not hard to produce both.
> >
> > For your point (2):
> > That's a bias you have against XML, no two ways about it.  I tend to
> > prefer to run XML through a sax-style parser and pull out what I want.
> > But, doing data binding is reasonable if one is dealing with complex
> data structures.
> > WebFinger is not so complex that it would need to be done that way,
> > but so what if developers did?  It's their code.  A lot of web
> > services have been written that way, so let developers choose.
> >
> > You conclude with "use JSON".  By that logic, we should send the HTML5
> > team back to the drawing board and have then re-write it in JSON.  Oh,
> > HTML is a document format.  Complex JSON isn't?  I'd argue it is
> > whatever you want to put in it.
> >
> > In any case, I'm not going to object if the consensus of the group is
> > to abandon XML entirely.  I personally do not care which format(s) we
> use.
> > What bothers me, though, is that we put a stake in the ground a few
> > years ago and people were happy until *very* recently.  Now, we want
> > to pull it out of the ground and put in a whole new one.
> >
> > Engineering protocols should involve thinking far down the road.  I
> > cannot fault anyone for having selected XML at the outset.  I cannot
> > fault anyone for wanting to add JSON support now for something this
> > simple to implement on the server.  However, what I call dangerous is
> > declaring that JSON should be the only format for the web, ignoring
> > the significant investment web developers have in XML.  The motivation
> > for JSON?  Because it works well with JavaScript, in spite of the fact
> > that nobody would want to do an eval on it, so it has to be parsed
> > like any other format?  What about the next web language?  Would we
> invent a new format for that, too?
> >
> > re-inventing that wheel, too.  Oh yeah... that would be what was done
> > with OpenID Connect ;-)
> >
> > Seriously... is there no sense of maintaining backward compatibility
> > and rigidly defining protocols for the long-term?
> >
> > Paul
> >
> >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
> >> Discovery
> >> (SWD)
> >>
> >> >> 1.  Being able to always discover per-user information with a
> >> >> single GET (minimizing user interface latency for mobile devices,
> >> >> etc.)
> >> >
> >> > WF can do that.  See:
> >> >> 2.  JSON should be required and it should be the only format
> >> >> required (simplicity and ease of deployment/adoption)
> >> >
> >> > Note, and very important note: supporting both XML and JSON would
> >> > only be a server-side requirement.  The client is at liberty to use
> >> > the format it prefers.  I would agree that forcing a client to
> >> > support both would be unacceptable, but the server?  Nothing to it.
> >> >
> >> > I believe WebFinger meets those requirements.  We could debate
> >> > whether XML should be supported, but I'll note (again) that it is
> >> > there in RFC
> >> 6415.
> >> > That document isn't all that old and, frankly, it concerns me that
> >> > we would have a strong preference for format A one week and then
> >> > Format B
> >> the next.
> >> > We are where we are and I can see reason for asking for JSON, but
> >> > no good reason to say we should not allow XML (on the server side).
> >> >
> >> > Paul
> >> >
> >> >

---

From: Mike Jones <[email-masked]>
Date: Fri, 20 Apr 2012 05:48:49 +0000

To be clear, making this mandatory would break no clients.  It would require updating some servers, just as requiring JSON would.  This seems like a fair tradeoff when it makes an appreciable difference in user interface latency in some important scenarios.  If you and the other key WebFinger supporters can agree to making "resource" support mandatory and requiring JSON, I believe we may have a path forward.

				Cheers,
				-- Mike

-----Original Message-----
From: Paul E. Jones [mailto:[email-masked]] 
Sent: Thursday, April 19, 2012 10:39 PM
To: Mike Jones; 'Murray S. Kucherawy'; [email-masked]; 'Apps Discuss'
Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

That's correct.  We could certainly make it mandatory, but the reason it isn't is to maintain backward compatibility with existing deployments.

I think we should always think carefully when we decide to make a change that breaks backward-compatibility.  This is one change that would do that.

Paul

> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web 
> Discovery
> (SWD)
> 
> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web 
> Discovery
> (SWD)
> 
> Mike,
> 
> It took me less than 10 minutes to code up both XML and JSON representations.
> Once the requested format is determined, the requested URI is 
> determined, data is pulled from the database, spitting out the desired 
> format is trivial.
> 
> XML should be supported, but I'll note (again) that it is there in RFC 6415.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 20 Apr 2012 02:00:33 -0400

Oh, don't scare people with that ;-)

If we do extend the syntax of WF, we should ensure that both formats are
extended in a natural way for each format.  Backward compatibility should
also be of utmost concern, so changes should never be too drastic.

Paul

> From: Goix Laurent Walter [mailto:[email-masked]]
> Sent: Friday, April 20, 2012 1:49 AM
> To: Tim Bray; Paul E. Jones
> Cc: [email-masked]; Apps Discuss
> Subject: R: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery
> (SWD)
> 
> I also would be in favor of keeping both, for the reasons mentioned. Plus
> xml is traditionally better than json at handling extensions & namespaces
> that may appear throughout future deployments
> 
> walter
> 
> > -----Messaggio originale-----
> > Da: [email-masked] [mailto:apps-discuss-
> > [email-masked]] Per conto di Tim Bray
> > Inviato: venerdì 20 aprile 2012 7.33
> > A: Paul E. Jones
> > Cc: [email-masked]; Apps Discuss
> > Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
> > Discovery (SWD)
> >
> > http://goo.gl/v7Pjr - but they say the same thing, more or less, that
> > MNot did.  Your characterizing me as an enemy of XML is amusing, given
> > that my name appears at the top of this document: http://goo.gl/lBjkl
> >
> > The points 1 & 2 you're reacting to are from someone else.  But we
> > agree that the choice of formats isn't crucial. Where we disagree is
> > that we should pick just one, not multiple ones.  -T
> >
> > the
> > > I implement various web services, largely for my own use.  Usually,
> > > I implement all of them in XML, JSON, plain text (attribute/value
> > pairs), AND
> > > JavaScript (for JSONP).  For simple services, it's not hard.  I do
> > > it because I sometimes have different wants/desires on the client
> side.
> >  (For
> > exist and
> > prefer
> > > to run XML through a sax-style parser and pull out what I want.
> > > But,
> > doing
> > but so
> > > what if developers did?  It's their code.  A lot of web services
> > > have
> > been
> > to
> > years
> > cannot
> > > on the server.  However, what I call dangerous is declaring that
> > > JSON
> > should
> > > with JavaScript, in spite of the fact that nobody would want to do
> > > an
> > eval
> > > This is like throwing out a widely deploy authentication protocol
> > > and re-inventing that wheel, too.  Oh yeah... that would be what was
> > > done
> > with
> > > OpenID Connect ;-)
> > >
> > and
> > single
> > required
> > only
> > >> > be a server-side requirement.  The client is at liberty to use
> > >> >> requirements discussion is probably the most productive one to
> > >> >> be having at this point - not the starting point document.
> > >> >
> > whether
> > >> > XML should be supported, but I'll note (again) that it is there
> > >> > in
> > RFC
> > >> 6415.
> > we
> > no
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate.
> Qualora abbiate ricevuto questo documento per errore siete cortesemente
> pregati di darne immediata comunicazione al mittente e di provvedere alla
> sua distruzione, Grazie.
> 
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the
> intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 20 Apr 2012 02:11:10 -0400

Mike,

Deal. :-)

Paul

> To be clear, making this mandatory would break no clients.  It would
> require updating some servers, just as requiring JSON would.  This seems
> like a fair tradeoff when it makes an appreciable difference in user
> interface latency in some important scenarios.  If you and the other key
> WebFinger supporters can agree to making "resource" support mandatory and
> requiring JSON, I believe we may have a path forward.
> 
> 				Cheers,
> 				-- Mike
> 
> representations.

---

From: Tim Bray <[email-masked]>
Date: Thu, 19 Apr 2012 20:41:05 -0700

No. Supporting two different on-the-wire data formats is actively
harmful.  Here are two pieces which explain why:

- mnot, this month: http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide
- Me, back in 2009

Pick one. -T

---

From: Tim Bray <[email-masked]>
Date: Thu, 19 Apr 2012 22:32:41 -0700

The points 1 & 2 you’re reacting to are from someone else.  But we
agree that the choice of formats isn’t crucial. Where we disagree is
that we should pick just one, not multiple ones.  -T

---

From: Goix Laurent Walter <[email-masked]>
Date: Fri, 20 Apr 2012 07:48:53 +0200

I also would be in favor of keeping both, for the reasons mentioned. Plus xml is traditionally better than json at handling extensions & namespaces that may appear throughout future deployments

walter

> >> > good reason to say we should not allow XML (on the server side).

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Fri, 20 Apr 2012 02:21:22 -0400

Mike - 

I can get behind this approach.

(Note: We already mandated JSON in the current WebFinger spec)

Cheers,

Gonzalo

---

From: Derek Atkins <[email-masked]>
Date: Fri, 20 Apr 2012 10:17:51 -0400

Paul,

> more complex ones, I use XML.)

As an individual (and not the chair of OAUTH) I believe that the server
should be allowed, no encouraged, to support multiple formats for data
retrieval.  I also believe that clients should be allowed to choose only
one.  I am fine with JSON being Mandatory to Implement.  I am NOT okay
with making it the only one, and I am even less okay with mandating it
is the ONLY one.  I would say MUST JSON, MUST (or possibly SHOULD -- you
can convince me either way) XML, and MAY for anything else that people
feel stronly about (although I feel in 2012 XML and JSON are the two
best).  I also feel it is okay to say that a client MUST implement one
of JSON or XML, and MAY implement more.

<OAUTH Chair Hat>

Note that this is a replay of the historical "MUST Implement" versus
"MUST Use" arguments.  Just because the server MUST IMPLEMENT JSON and
XML does not mean that a Client must use both (or even that a client
must implement both).  It is perfectly reasonable and generally
acceptable to have a server that provides data in multiple formats
whereas the client only supports a subset and specifies which format(s)
are acceptable.

</OAUTH Char Hat>

-derek

---

From: Michael Thomas <[email-masked]>
Date: Fri, 20 Apr 2012 07:40:05 -0700

On 04/20/2012 07:17 AM, Derek Atkins wrote:
> Paul,
>
> "Paul E. Jones"<[email-masked]>  writes:
>
>> Tim,
>>

Why not MUST ASN.1 while you're at it? JSON has won in case
you'all haven't noticed it.

Mike

---

From: Melvin Carvalho <[email-masked]>
Date: Fri, 20 Apr 2012 16:44:29 +0200

+1

Also bear in mind that when people say "XML" here, it's a specific subset
of XML namely "application/xrd+xml".

> Mike
>
> ______________________________**_________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: William Mills <[email-masked]>
Date: Fri, 20 Apr 2012 07:45:23 -0700 (PDT)

So you are guaranteeing that there are no clients using WF today?  

> From: Mike Jones <[email-masked]>
>To: Paul E. Jones <[email-masked]>; 'Murray S. Kucherawy' <[email-masked]>; "[email-masked]" <[email-masked]>; 'Apps Discuss' <[email-masked]> 
>Sent: Thursday, April 19, 2012 10:48 PM

---

From: Tim Bray <[email-masked]>
Date: Fri, 20 Apr 2012 08:12:13 -0700

There's a disconnect here. Mnot and I (at least) have argued that
there are very specific problems and costs associated with going
multi-format.  I’ve heard lots of people say "Well, I support
multi-format” but I haven’t heard any specific responses explaining
why those costs and problems aren’t real, or why the benefits are
sufficiently great that we should just accept them.

Mnot: JSON or XML: Just Decide
http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide
tbray: Case Study: Atom and/or JSON
http://www.tbray.org/ongoing/When/200x/2009/04/29/Model-and-Syntax#p-1

Would this work better if I summarized the problems here inline in
this thread?  It may be the pace that people’s IETF/email workflow is
such that they’re not able comfortably to consult external references?

 -Tim

---

From: Michael Thomas <[email-masked]>
Date: Fri, 20 Apr 2012 08:12:38 -0700

On 04/20/2012 07:17 AM, Derek Atkins wrote:
> <OAUTH Chair Hat> Note that this is a replay of the historical "MUST Implement" versus "MUST Use" arguments. Just because the server MUST IMPLEMENT JSON and XML does not mean that a Client must use both (or even that a client must implement both). It is perfectly reasonable and generally acceptable to have a server that provides data in multiple formats whereas the client only supports a subset and specifies which format(s) are acceptable. </OAUTH Char Hat> -derek 

To Paul's point about how easy it is for a server to support both, I'd
retort that it's equally easy for a client to gin up JSON instead of XML.
Pity the poor programmer who can't get their head around that gigantic
change. On the other hand, having to support XML and JSON is an ongoing
maintenance headache server-side. Why do it? There isn't even the dubious
religious war like back in the day saying that binary encoded ASN.1 was
"better/faster/stacks and cleans dishes" than "human readable" XML.  XML
is just a clunky and past its prime text encoding at this point. Requiring it
smacks of nostalgia to me.

Mike

---

From: John Bradley <[email-masked]>
Date: Fri, 20 Apr 2012 17:12:23 +0200

We are not arguing that XML be removed from the server.  Only that JSON be mandatory for the server to support.

Others on the list piled on the removing XML argument.   

I do think there is a legitimate argument that fewer options make for better interoperability.

However Mike and myself are not the ones making that argument.

Only that the server MUST support JSON.

The other MUST Mike had was getting the JRD with a single get and not needing to retrieve the host-meta file first to retrieve the template.

That is probably the largest design difference.

SWD uses a .well-known location as effectively a static template and only redirects if necessary.

Where as Web Finger assumes the overhead of one extra GET on the first request to add a configurable template.

one compromise and perhaps not the best is to leave the current host-meta mechanism.
Add a new SWD endpoint (fixed-template) in .well-known that provides the service, or is an alias for the host-mata file.

A client could try the SWD endpoint (fixed template first and get a response in one go, or get back a  host meta file and take the template from that and try again.

A redirect might be better as that could be cached. ( open to debate)

That would make the happy path discovery for web-finger be one GET and possibly some people happy.

The existing clients would get .well known and get the template as they do now.

The single GET could be considered an optimization.

If we pick off the issues one at a time I hope we can find solutions.

John B.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Apr 2012 17:31:22 +0200

On 2012-04-20 17:12, Michael Thomas wrote:
> ...
> ...

What's sure is that with generalizations like these, you're not going to 
convince anybody.

JSON is simpler than XML. Sometimes it's too simple.

In my experience, testing HTTP interfaces that return XML is more 
pleasant as a browser will actually *display* the response (and allow it 
to be transformed to HTML client-side), while it will pop up a download 
dialogue for application/json. Maybe it's time to fix the latter?

Best regards, Julian

---

From: Michael Thomas <[email-masked]>
Date: Fri, 20 Apr 2012 08:51:24 -0700

On 04/20/2012 08:31 AM, Julian Reschke wrote:
> What's sure is that with generalizations like these, you're not going to convince anybody.
>
> In my experience, testing HTTP interfaces that return XML is more pleasant as a browser will actually *display* the response (and allow it to be transformed to HTML client-side), while it will pop up a download dialogue for application/json. Maybe it's time to fix the latter?
>

It may be a generalization, but it's based on direct experience. I create and use
JSON for fairly complex data structures transferred server->client (it's a ski tracking
app) and I have never once thought "gosh, I wish that I had the expressiveness
of XML here". On the input side of uploading points to the server, I use a home
grown XML scheme purely for my own historical reasons and I do often wish that
I could get rid of it. The worst of all possible worlds would be to require support
for both on the input and output side. Bletch. Just the testing requirements
would be onerous.

I also know that, oh say, twitter supports XML and JSON in their API. Probably
lots of companies do. I'll bet if you asked them now, they'd say they wish they
hadn't supported XML at this point because it's nothing more than overhead,
keeping some dev and devtest folks gainfully employed.

Mike, and I don't have a problem viewing JSON in a browser

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Fri, 20 Apr 2012 13:09:48 -0400

Derek - 

> whereas the client only supports a subset and specifies which format(s)

This is the most sensible path forward.  A MUST for JSON and XML (I'm going with a MUST for XML to maintain backwards compatibility with RFC 6415) on the server side and a client can choose whatever format it wants. This is the approach taken in the current WebFinger draft. If we reach consensus that we must mandate a client format (Note: I don't personally think we need to), then so be it.

Cheers,

Gonzalo

---

From: John Bradley <[email-masked]>
Date: Fri, 20 Apr 2012 19:23:06 +0200

I would be OK with optional XML support in the server,  that way existing endpoints will continue to work, but new ones are not required to add something some people feel is cruft.

As one of the XRD authors, I do understand the advantages of it.

However I don't want to be sentimental, and force people to carry forward things that won't be used, and may hamper adoption.

And Yes I am one of the hard hatred basters that decided to redo  openID on OAuth rather than trying to graft OAuth functionality onto openID 2.   

Keeping what's working working is fine,  but not forcing people to carry it forward.

John B.

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Fri, 20 Apr 2012 13:34:41 -0400

John - 

I understand your position, I truly do.  I'd even go so far as saying that a part of me agree with you given the ubiquitousness of JSON. Two concerns/questions come to mind:

- If it is a MUST in 6415, then isn't it simply good protocol design to maintain that same level of requirement in the discovery protocol based entirely on it? If the answer is "no", then we can figure something out but I'm sharing that this was our primary motivation for requiring it in WebFinger.

- Is it alarming to anyone how quickly we go through "flavor of the day" formats? 6415 was published 6 months ago and we are already ready to declare the mandatory format there a dinosaur that is now obsolete and unnecessary?

Cheers,

Gonzalo

---

From: John Bradley <[email-masked]>
Date: Fri, 20 Apr 2012 20:52:36 +0200

6415 supporting a XML format doesn't require everything that uses it to support XML. 

John B  

Sent from my iPhone

On 2012-04-20, at 7:34 PM, Gonzalo Salgueiro <[email-masked]> wrote:

> 6415

---

From: George Fletcher <[email-masked]>
Date: Fri, 20 Apr 2012 15:58:25 -0400

And the AOL is working as well (though it was down for a bit:)

On 4/19/12 12:15 PM, Christian Weiske wrote:
> Hello Dick,
>
>
>>> Gmail, aol, and yahoo all put up webfinger endpoints, but there
>>> hasn't been much movement, I think due to the chicken and egg
>>> nature of adoption around decentralized tools.
>> A couple months ago I was checking out what was up. The AOL and Yahoo
>> endpoints no longer worked. The Google one still did.
> Yahoo actually still serves the main entry point at
> http://www.yahoo.com/.well-known/host-meta
> that gives out the OpenID all accounts can use.
>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 21 Apr 2012 03:41:23 +0100

> you'all haven't noticed it.

Well, I also remember when XML won over ASN.1, or
was that some RPC thing? Seems like a new format wins
about every five years or so, once the last winner
gets enough crap added. (JSON pointer seems like the
start of a nice slippery slope to me.)

I've no opinion as to what should be MTI here however,
just a side comment.

S

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 20 Apr 2012 23:34:08 -0400

Derek,

> with making it the only one, and I am even less okay with mandating it is
> the ONLY one.  I would say MUST JSON, MUST (or possibly SHOULD -- you can
> convince me either way) XML, and MAY for anything else that people feel
> stronly about (although I feel in 2012 XML and JSON are the two best).  I
> also feel it is okay to say that a client MUST implement one of JSON or
> XML, and MAY implement more.

I hope I didn't mislead you with my statements.  I definitely was not
suggesting we have more than XML and JSON on the server.  I was merely
pointing out that I've found it fairly simple on the server side to offer
multiple formats.  Spewing data out in some format is trivial, usually.

My preference has been MUST for XML and JSON since 1) XML is already a MUST
in RFC 6415 and we'd have to "break" what is there now to remove the MUST
and 2) people are clearly demanding JSON.
 
> <OAUTH Chair Hat>
> 
> Note that this is a replay of the historical "MUST Implement" versus "MUST
> Use" arguments.  Just because the server MUST IMPLEMENT JSON and XML does
> not mean that a Client must use both (or even that a client must implement
> both).  It is perfectly reasonable and generally acceptable to have a
> server that provides data in multiple formats whereas the client only
> supports a subset and specifies which format(s) are acceptable.
> 
> </OAUTH Char Hat>

Definitely... clients would only have to implement what they prefer.  Only
the server would be required to implement both.  (Still, there is contention
over requiring both on the server.)

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 21 Apr 2012 00:11:15 -0400

Mike,

> > <OAUTH Chair Hat> Note that this is a replay of the historical "MUST
> > Implement" versus "MUST Use" arguments. Just because the server MUST
> > IMPLEMENT JSON and XML does not mean that a Client must use both (or
> > even that a client must implement both). It is perfectly reasonable
> > and generally acceptable to have a server that provides data in
> > multiple formats whereas the client only supports a subset and
> > specifies which format(s) are acceptable. </OAUTH Char Hat> -derek
> 

I don't follow.

I agree I could write a client that could do JSON easily.
I agree I could write a client that could do XML easily.

What is a pain on the client side is conditional code that has to be
followed in order to consume whatever the server wants to send.  The client
should have a single code path knowing it will get what it wants, ether XML
or JSON.

Granted, the server has to have a conditional statement and generate XML or
JSON as requested.  However, generating either is trivial.  Really, I did it
in minutes.  We're not talking about huge complex data structures here with
WebFinger.

> maintenance headache server-side. Why do it?

Would we expect to see a lot of changes to the data structures used by
WebFinger?  That's really the only ongoing maintenance issue.  Don't touch
the code that produces the XML or JSON and there is no ongoing maintenance.

> There isn't even the dubious
> is just a clunky and past its prime text encoding at this point. Requiring
> it smacks of nostalgia to me.

I disagree with you on that one.  First, ASN.1 is better for defining
protocols, so long as you stay away from the complex stuff. Basic ASN.1
looks a lot like C and produces C data structures that can be readily read,
decoded, and consumed in C code.  Rarely, rarely do I see decoding issues
when using ASN.1, whereas issues pop up quite often with text protocols,
especially things like SIP where a semi-colon in the wrong place breaks
things.  But, let's not start that debate again ;-)

XML *can* be big and clunky.  As you've well noticed, I can also write
lengthy emails that seem to have more typos as the evening progresses. :-)

However, XML can be a very compact encoding and it's extremely readable.

I just did a query on my server to see the XML vs. JSON output.  The XRD
document provided was 1032 octets.  The JRD document was 1077 octets.
Removing every possible space and making both formats hard as heck to read,
JSON was 837 and XML was 940.  I'm hard pressed to say that's makes much
difference.  Further, I can't read either of them now without some effort.

Considering that a lot of WebFinger use (I suspect) is going to be
server-to-server interaction, XML seems like a reasonable format to retain.
That, and the fact it is already mandatory in RFC 6415 and deployed out
there.

It's not nostalgia for me.  XML is a very well-structured, readable format.
No objection to JSON, but I really don't understand the clamoring for JSON.
I guess more precisely, I don't understand the disdain for XML.  Is it
because people created hideously complex XML data structures and feel pain
for having done that?  XRD is not that kind of document.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 21 Apr 2012 00:24:25 -0400

Daniel,

If the resource parameter is required, what would break are new clients that rely on it.  Thus, we have a forward-compatibility issue.  That is an issue, which is why we made it optional.  (But I've said that.)

I think a question is whether we can accept this "new client" issue as an interim situation while servers are upgraded to support the resource parameter.  If people feel the answer is "no" then we need to keep it optional.  If "yes", we could make it mandatory.

We also have those who want to be able to run WebFinger on static sites.  It's hard to ignore that if there are really those who want to do it.

On the SWD side, there is clearly a desire to be able to make a single query and get a single response.  I can appreciate that, since otherwise one would have to perform two queries and construct the JRD on the client side (or at least go sifting through replies looking for the proper link relations and values).

Paul

> From: Daniel Renfer [mailto:[email-masked]]
> Sent: Friday, April 20, 2012 11:09 AM
> To: William Mills
> Cc: Mike Jones; Paul E. Jones; Murray S. Kucherawy; [email-masked]; Apps
> Discuss
> The point is that existing WF clients have been written to not use the
> resource parameter because in the past, that parameter hasn't been
> available or hasn't been reliable.
> 
> If the resource parameter is required, this older method of fetching the
> host meta and constructing the url to fetch the user meta would still
> continue to work just as before.
> 
> Even if the resource parameter were made mandatory today, real world WF
> clients would still have to account for the possibility of resource
> queries resulting in an error or incorrect information. Given the number
> of currently deployed WF-enabled services and the difficulty in upgrading
> all of them, this is going to be the case for some time.
> 
> resource parameters should be strongly encouraged, but not required.
> 
> On Fri, Apr 20, 2012 at 10:45 AM, William Mills <[email-masked]>
> wrote:
> > To: Paul E. Jones <[email-masked]>; 'Murray S. Kucherawy'
> > <[email-masked]>; "[email-masked]" <[email-masked]>; 'Apps Discuss'
> > <[email-masked]>
> > Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web
> > Discovery
> > (SWD)
> >
> > require updating some servers, just as requiring JSON would.  This
> > seems like a fair tradeoff when it makes an appreciable difference in
> > user interface latency in some important scenarios.  If you and the
> > other key WebFinger supporters can agree to making "resource" support
> > mandatory and requiring JSON, I believe we may have a path forward.
> >
> >                 Cheers,
> >                 -- Mike
> >
> > That's correct.  We could certainly make it mandatory, but the reason
> > it isn't is to maintain backward compatibility with existing
> deployments.
> >
> > I think we should always think carefully when we decide to make a
> > change that breaks backward-compatibility.  This is one change that
> would do that.
> >
> > Paul
> >
> >> determined, data is pulled from the database, spitting out the
> >> desired format is trivial.
> >>
> >> there in RFC 6415.
> >> would have a strong preference for format A one week and then Format
> >> B the next.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 21 Apr 2012 00:39:30 -0400

Michael,

> > am NOT okay with making it the only one, and I am even less okay with
> > mandating it is the ONLY one.  I would say MUST JSON, MUST (or
> > possibly SHOULD -- you can convince me either way) XML, and MAY for
> > anything else that people feel stronly about (although I feel in 2012
> > XML and JSON are the two best).  I also feel it is okay to say that a
> > client MUST implement one of JSON or XML, and MAY implement more.
> >
> >
> 
> Why not MUST ASN.1 while you're at it? JSON has won in case you'all
> haven't noticed it.

"Won"? Data formats are not popularity contests.  This is the Internet
Engineering Task Force, not the Internet Entertainment Task Force.  (That
said, a few recent message have been entertaining.)  We should be building
and designing systems for longevity.  XML was absolutely *the* thing just a
few years ago and now JSON is all the rage.  How long will that last before
"the next great thing" comes along?

There are many people who value XML still, in spite a growth in the use of
JSON.

Paul

---

From: Tim Bray <[email-masked]>
Date: Sat, 21 Apr 2012 12:26:59 -0700

That might have happened had there been some free high-quality ASN.1
software, instead of slow buggy parsers that cost $50K to license.
It’s always seemed to me that one reason XML took off so fast is that
there were fast robust open-source parsers in C and Java before the
spec was even finalized.

But we digress... -T

On Sat, Apr 21, 2012 at 10:14 AM, Bob Wyman <[email-masked]> wrote:
>
>
> On Fri, Apr 20, 2012 at 10:41 PM, Stephen Farrell
> <[email-masked]> wrote:
>>
>>
>>
>> was that some RPC thing?
> Of course, long before "XML won over ASN.1" ASN.1 won over XML's
> predecessor; SGML. Back in the early to mid-80's, when we were defining the
> ISO X.4xx and X.5xx standards, the IBM and Unix crowds were pushing SGML as
> the alternative to the binary encodings of ASN.1. But, Digital and the
> Telcos pushed for the binary encodings and won.
>
> These days, XML is just another encoding for ASN.1 since ASN.1 finally
> defined the XML Encoding Rules (XER) a few years back.
>
> If we had agreed on ASN.1 years ago, we wouldn't be having these encoding
> format debates every few years. ASN.1 is an "Abstract Syntax Notation" that
> can be mapped to a large number of encoding rules. If we were using ASN.1,
> what we would do is define the "schema" or syntax for data abstractly and
> then specify the actual encoding as a secondary issue. Given that one
> encoding can be translated to another, implementations would be free to use
> whatever encoding was most convenient or appropriate for them. But, that
> would be a different universe than the one we live in today.
>
>> Seems like a new format wins

---

From: SM <[email-masked]>
Date: Sat, 21 Apr 2012 13:03:53 -0700

Hi Paul,
>and 2) people are clearly demanding JSON.

MUST for XML and JSON offers choice but it does make a 
choice.  Encouraging such a polygamous relationship can only end up 
badly.  RFC 6415 was published in October 2011.  Switching 
preferences in less than a year raises some issues about the nature 
of relationships.

Anyway, whether someone break something is not as important as 
picking one option.

Regards,
-sm

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 21 Apr 2012 23:45:14 -0400

Note that requiring both would only be on the server side. While JSON might be the new hip format, I suspect some will use XML for some time. And there are some link relations that might point to XML content. For certain applications like OpenID Connect, they could get by with JSON only, but I bet many other applications will have to deal with a variety of content types, like hcard, vcard, portable contacts, and others that might use something else.

Paul

-------- Original Message --------
From: SM <[email-masked]>
Sent: Sat Apr 21 16:03:53 EDT 2012
To: "Paul E. Jones" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web  Discovery (SWD)

Hi Paul,

Regards,
-sm

---

From: Derek Atkins <[email-masked]>
Date: Mon, 23 Apr 2012 10:54:21 -0400

> you'all haven't noticed it.

Well, now that you mention it...   ;-)

But seriously, we're basing this work on an RFC that was just release
six months ago and it requires XML.  Why be so quick to drop something
we just published half a year ago?  So maybe in 6 months we drop JSON
and add the next big thing?  Come on, Mike.

I agree, we should definitely support JSON.  But I also think we should
support XML.  The client can do what it wants, which is where want the
light weight implementation.

-derek

---

From: Derek Atkins <[email-masked]>
Date: Mon, 23 Apr 2012 11:04:34 -0400

> such that they’re not able comfortably to consult external references?

No, but I disagree with your conclusions.  Indeed, I disagree with your
problem statement.  Just because the server supports multiple formats
does NOT imply more work for the client.  The client can request a
specific format and never has to worry about the other, so it has NOT
doubled the work on the other side.

Let's take your rails example.  Yes, it's simple for a rails server to
output HTML, XML, JSON, and other formats.  But no, this does NOT make
it harder for the consumer of that content.  The consumer can
specifically ask for whatever format it wants!  This means you can have
a JSON-only client and it can interact 100% with your rails application
using just JSON.  It doesn't have to worry about receiving XML, because
it will always get JSON.

As for your abstract model issue..  Maybe Mike was right and we SHOULD
use ASN.1!  :-D Then we could have defined encodings to XML or JSON ;)

-derek

---

From: Michael Thomas <[email-masked]>
Date: Mon, 23 Apr 2012 08:23:02 -0700

> light weight implementation.

I think you're probably misunderstanding me. I'm (I believe) with Tim
in saying "pick one". Just one. For clients and servers. And I'm only
saying that JSON is preferable because it has pretty much taken
over -- I see JSON all the time with webbish ajax-y data stuff and XML
almost never unless it's something vaguely markup-like. JSON is clean
in a what you see is what you get kind of way, and I'm puzzled by people
calling a 6 year old RFC a "flavor of the day" -- c'mon.

 From a programming standpoint, JSON is just easier to deal with. Consider
these two links:

http://php.net/manual/en/book.json.php

http://php.net/manual/en/book.xml.php

and tell me which you'd rather deal with. It's not huge, but it's not
nothing either.

Mike

Mike

---

From: Daniel Renfer <[email-masked]>
Date: Fri, 20 Apr 2012 11:08:34 -0400

If the resource parameter is required, this older method of fetching
the host meta and constructing the url to fetch the user meta would
still continue to work just as before.

Even if the resource parameter were made mandatory today, real world
WF clients would still have to account for the possibility of resource
queries resulting in an error or incorrect information. Given the
number of currently deployed WF-enabled services and the difficulty in
upgrading all of them, this is going to be the case for some time.

On Fri, Apr 20, 2012 at 10:45 AM, William Mills <[email-masked]> wrote:
> To be clear, making this mandatory would break no clients.  It would require
> updating some servers, just as requiring JSON would.  This seems like a fair
> tradeoff when it makes an appreciable difference in user interface latency
> in some important scenarios.  If you and the other key WebFinger supporters
> can agree to making "resource" support mandatory and requiring JSON, I
> believe we may have a path forward.
>
>                 Cheers,
>                 -- Mike
>

---

From: Mike Jones <[email-masked]>
Date: Sat, 21 Apr 2012 16:37:40 +0000

I want to completely agree with what Paul wrote: "What is a pain on the client side is conditional code that has to be followed in order to consume whatever the server wants to send.  The client should have a single code path knowing it will get what it wants".

BTW, this is also part of the argument for making the resource parameter required.  Paul's example of:
	curl -v https://packetizer.com/.well-known/host-meta.json?resource=acct:[email-masked]
should work on all deployments - not just packetizer.com, so clients can rely on it working (and not have to have conditional code to try again in a different way when it doesn't).

As a design principle, to the extent there's any complexity, it should be pushed to the servers, rather than the clients, as clients will vastly outnumber servers.    The solution should be as simple for clients to use as possible, to facilitate adoption.

				Best wishes,
				-- Mike

(moved OAuth to bcc)		

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul E. Jones
Sent: Friday, April 20, 2012 9:11 PM
To: 'Michael Thomas'; 'Derek Atkins'
Cc: [email-masked]; 'Apps Discuss'
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

Mike,

I don't follow.

What is a pain on the client side is conditional code that has to be followed in order to consume whatever the server wants to send.  The client should have a single code path knowing it will get what it wants, ether XML or JSON.

Granted, the server has to have a conditional statement and generate XML or JSON as requested.  However, generating either is trivial.  Really, I did it in minutes.  We're not talking about huge complex data structures here with WebFinger.

> change. On the other hand, having to support XML and JSON is an 
> ongoing maintenance headache server-side. Why do it?

Would we expect to see a lot of changes to the data structures used by WebFinger?  That's really the only ongoing maintenance issue.  Don't touch the code that produces the XML or JSON and there is no ongoing maintenance.

> religious war like back in the day saying that binary encoded ASN.1 
> was "better/faster/stacks and cleans dishes" than "human readable" 
> XML.  XML is just a clunky and past its prime text encoding at this 
> point. Requiring it smacks of nostalgia to me.

I disagree with you on that one.  First, ASN.1 is better for defining protocols, so long as you stay away from the complex stuff. Basic ASN.1 looks a lot like C and produces C data structures that can be readily read, decoded, and consumed in C code.  Rarely, rarely do I see decoding issues when using ASN.1, whereas issues pop up quite often with text protocols, especially things like SIP where a semi-colon in the wrong place breaks things.  But, let's not start that debate again ;-)

XML *can* be big and clunky.  As you've well noticed, I can also write lengthy emails that seem to have more typos as the evening progresses. :-)

I just did a query on my server to see the XML vs. JSON output.  The XRD document provided was 1032 octets.  The JRD document was 1077 octets.
Removing every possible space and making both formats hard as heck to read, JSON was 837 and XML was 940.  I'm hard pressed to say that's makes much difference.  Further, I can't read either of them now without some effort.

Considering that a lot of WebFinger use (I suspect) is going to be server-to-server interaction, XML seems like a reasonable format to retain.
That, and the fact it is already mandatory in RFC 6415 and deployed out there.

It's not nostalgia for me.  XML is a very well-structured, readable format.
No objection to JSON, but I really don't understand the clamoring for JSON.
I guess more precisely, I don't understand the disdain for XML.  Is it because people created hideously complex XML data structures and feel pain for having done that?  XRD is not that kind of document.

Paul

---

From: Bob Wyman <[email-masked]>
Date: Sat, 21 Apr 2012 13:14:53 -0400

On Fri, Apr 20, 2012 at 10:41 PM, Stephen Farrell <[email-masked]

These days, XML is just another encoding for ASN.1 since ASN.1 finally
defined the XML Encoding Rules
(XER)<http://www.itu.int/ITU-T/asn1/xml/xer.htm>a few years back.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 23 Apr 2012 16:15:24 +0900

> start of a nice slippery slope to me.)

There's a bit of that indeed. However, as others have noted, JSON is 
indeed better suited for exchanging *data* between programs, in 
particular between scripting languages, because their main datatypes are 
numbers and strings, and their main data structures are arrays and 
hashes (or whatever they are called).

In contrast to that, XML originated as a document format. It's way 
better than JSON for documents, and for mixed document/data situations, 
but if all you do is exchanging data (structures) between programs, JSON 
wins.

Regards,   Martin.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 23 Apr 2012 08:40:55 -0700

> I've no opinion as to what should be MTI here however,

As a producer of schemas for my own purposes, I always feel like I'm
likely doing something wrong when I hack up XML, and I'm most likely
right since I haven't -- and don't want to -- read half of the RFC's.
Not so with JSON. I read 4627 through and thought -- groovy, nothing
more than meets the eye! It's impossible to sin!

Mike, and yes JSON will turn to crap if it gets loved to death

---

From: Derek Atkins <[email-masked]>
Date: Mon, 23 Apr 2012 12:55:40 -0400

> in saying "pick one". Just one. For clients and servers. And I'm only

No, I'm not misunderstanding you, I know exactly what you are arguing
for.  And I'm agreeing with you that we must support JSON.  However, I
disagree that we should drop XML, especially considering 6415 requires
XML and it was just released 6 months ago.

I'm also saying that this is only a server-side requirement to support
both.  The client can choose to support only one based on its own
requirements.  If you already have an XML-based client, why force them
to add JSON support?  Similarly, if you already have a JSON-based
client, why force them to add XML support?

If you're writing a client, you can ignore XML and only play with JSON.

-derek

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 24 Apr 2012 01:56:32 -0400

Michael,

> and tell me which you'd rather deal with. It's not huge, but it's not

To be fair, this works well partly because of the language.  Works even
better in JavaScript.  It would work less well in C.  Here's just one
example:
http://www.digip.org/jansson/doc/2.3/

JSON bits do not map perfectly to C.  I thought C++ might be simpler, but
the first library I grabbed had library documentation that was 224 pages
long (libjson).

When I process simple XML like that from WebFinger, I tend to use a parser
that just steps through each node in order.  I don't need to decode the
whole "document" in memory and reference pieces and parts of it: one pass
over it and I grab what I need.  It's very simple to process the XML output
from WebFinger that way.

Paul

---

From: Kevin Marks <[email-masked]>
Date: Tue, 24 Apr 2012 09:43:07 -0700

I think you make JSON's point for it. It has a single, unambiguous,
bidirectional mapping to native data structures in all dynamic languages;
indeed that is its design goal.

XML does not map well to language structures, except in languages designed
explicitly to manipulate it. The duality of elements and attributes means
additional choices at each encode/decode boundary, and guaranteed ambiguity.

To continue the argument made by mark Nottingham and Tim Bray, having to
choose between attributes and elements at each point imposes the same
overhead at a different layer than having to choose between xml and json.

Yes, this natural mapping does not hold true for C, because C doesn't have
a native dictionary/hashtag data structure. C doesn't make XML or anything
else easy either, but C programmers are used to that.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 24 Apr 2012 14:00:42 -0700

On 04/23/2012 09:55 AM, Derek Atkins wrote:
> Michael Thomas<[email-masked]>  writes:
>
>> Derek Atkins wrote:
>>> Michael Thomas<[email-masked]>  writes:
>>>

Derek -- I think that the modern reality is that most things can
support both without much problem from a code footprint and
library availability standpoint,  both client and server. But that
misses a larger point of whether we _should_ just because we
_can_. There is a cost to maintaining two different encoding/
decoding both on the implementation side, as well as the
specification (and the debugging thereof) side. So my feeling
is that "chose one" should *always* be a SHOULD in the way
that Stephen outlined as well. If that means choosing XML
mainly for historical reasons, that's still better than trying to
placate both sides or "facilitating the transition" or any other
reason on offer.

Mike