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

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

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.

>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

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.

On 04/12/2012 12:00 PM, Hannes Tschofenig wrote:
> Hi all, 
> 
> those who had attended the last IETF meeting may have noticed the ongoing activity in the 'Applications Area Working Group' regarding Web Finger. 
> We had our discussion regarding Simple Web Discovery (SWD) as part of the re-chartering process. 
> 
>  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: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 13 Apr 2012 17:45:32 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Friday, April 13, 2012 9:23 AM
> To: [email-masked] WG
> Cc: Apps Discuss
> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
> 
> 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: Peter Saint-Andre <[email-masked]>
Date: Mon, 16 Apr 2012 11:55:46 -0600

On 4/13/12 11:45 AM, Murray S. Kucherawy wrote:
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Stephen
>> Farrell Sent: Friday, April 13, 2012 9:23 AM To: [email-masked]
>> WG Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web
>> Finger vs. Simple Web Discovery (SWD)
>> 
>> 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.
>> 
>> - 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.
> 
> 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.

I've just had a chance to review both I-Ds:

https://datatracker.ietf.org/doc/draft-jones-appsawg-webfinger/ (-03)

http://datatracker.ietf.org/doc/draft-jones-simple-web-discovery/ (-02)

Although at a later time I will provide more detailed feedback, I am
left wondering why Simple Web Discovery was developed. It appears to
solve the same problem as WebFinger (which predates SWD by several
years as far as I can see) in similar ways (/.well-known/ etc.), with
a few tweaks and optimizations (some of which might be premature IMHO).

Thus I think it would be helpful for the authors of SWD to explain why
they didn't use WebFinger, or provide feedback that would improve
WebFinger if it didn't address some of their use cases (I note that
the more recent WebFinger I-Ds include some SWD-ish features, such as
the "resource" parameter -- whether that is a good thing remains to be
determined). Although draft-jones-simple-web-discovery does not
contain such an analysis, perhaps someone posted it to the OAUTH WG
list or elsewhere, in which case I apologize for having missed it.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 16 Apr 2012 20:00:14 +0200

On 16 April 2012 19:55, Peter Saint-Andre <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

+1

> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk+MXSIACgkQNL8k5A2w/vzR4ACffCIM6A/RBj/y6RdyiudN+AF2
> deMAoKmuesVvyS8yYVb0sqYXqCJnQF8+
> =3OKr
> -----END PGP SIGNATURE-----
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 16 Apr 2012 20:41:39 +0000

You can read a lot of the rationale for why Simple Web Discovery was developed in these posts:  	http://www.goland.org/simplewebfinger/
	http://www.goland.org/managingfingerservice/

BTW, I'll point out that Stephen requested that we move this discussion to the Apps Discuss list, so while I'm replying here, people should follow up there.  (Although I'll warn you, the traffic volume there is fierce - even compared to the OAuth list at its high water marks.)

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Monday, April 16, 2012 10:56 AM
To: Murray S. Kucherawy
Cc: Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

On 4/13/12 11:45 AM, Murray S. Kucherawy wrote:
>> [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)
>> 
>> 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.
>> 
>> 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.
>> 
>> - 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.
> 
> documents in "Call for Adoption" state in the datatracker for appsawg.
> 
> Let the games begin.

Although at a later time I will provide more detailed feedback, I am left wondering why Simple Web Discovery was developed. It appears to solve the same problem as WebFinger (which predates SWD by several years as far as I can see) in similar ways (/.well-known/ etc.), with a few tweaks and optimizations (some of which might be premature IMHO).

Thus I think it would be helpful for the authors of SWD to explain why they didn't use WebFinger, or provide feedback that would improve WebFinger if it didn't address some of their use cases (I note that the more recent WebFinger I-Ds include some SWD-ish features, such as the "resource" parameter -- whether that is a good thing remains to be determined). Although draft-jones-simple-web-discovery does not contain such an analysis, perhaps someone posted it to the OAUTH WG list or elsewhere, in which case I apologize for having missed it.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 16 Apr 2012 14:44:26 -0600

On 4/16/12 2:41 PM, Mike Jones wrote:
> You can read a lot of the rationale for why Simple Web Discovery
> was developed in these posts:
> http://www.goland.org/simplewebfinger/ 

Thanks, I'll read those!

> BTW, I'll point out that Stephen requested that we move this 
> discussion to the Apps Discuss list, so while I'm replying here, 
> people should follow up there.

In fact I removed [email-masked] from my message, so it went only to
apps-discuss.

> (Although I'll warn you, the traffic volume there is fierce - even
> compared to the OAuth list at its high water marks.)

Clearly you weren't on the hybi list -- that one was truly memorable.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

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

---

From: Melvin Carvalho <[email-masked]>
Date: Tue, 17 Apr 2012 16:02:03 +0200

On 16 April 2012 22:41, Mike Jones <[email-masked]> wrote:

> You can read a lot of the rationale for why Simple Web Discovery was
> developed in these posts:          http://www.goland.org/simplewebfinger/

Thanks for sharing this

A couple of points:

1. JSON
=======

I think at the time webfinger was created in 2009, XML was the de facto
serialization, used in AJAX, SOAP and many other systems.  Today I'm
hearing more and more, that both developers and publishers, want to work
with JSON, rather than, having to support both xml and json.  Content
negotiation also confuses some publishers.  In my view, this is a great
simplification that webfinger can learn from SWD.

2. acct: scheme
=============

The acct: URI scheme has not proved popular, imho, and has added a layer of
complexity and confusion.  How do we get from acct: to mailto:?  When
should you use acct: and when mailto: (the spec says acct:user@host may be
different from mailto:user@host).  What about the forms.  How about linked
data ecosystems that want to cross link identifiers, do they now have to
consider both cases?

>From the original post introducing acct:

"I don’t expect everyone to like this idea. I wish I could say I love it,
but I am simply content with it."

I dont know of anyone in the community (and correct me if this has changed)
that really loves acct:, or perhaps even likes the acct: idea.  SWD has
shown you can do discovery without acct: and I think that's a big plus.

One final side note is that this almost becomes trivial when you can do
SPARQL queries.  "void" is already registered by the W3C with IANA in
.well-known in order to discover SPARQL endpoints.  It may be overkill in
some people's eyes, but Linked Data (which predates webfinger),
particularly newer things like JSON LD, are a lot bigger than they were in
2009.  In a few years it may become the definitive discovery mechanism
anyway.

>
> BTW, I'll point out that Stephen requested that we move this discussion to
> the Apps Discuss list, so while I'm replying here, people should follow up
> there.  (Although I'll warn you, the traffic volume there is fierce - even
> Although at a later time I will provide more detailed feedback, I am left
> wondering why Simple Web Discovery was developed. It appears to solve the
> same problem as WebFinger (which predates SWD by several years as far as I
> can see) in similar ways (/.well-known/ etc.), with a few tweaks and
> optimizations (some of which might be premature IMHO).
>
> they didn't use WebFinger, or provide feedback that would improve WebFinger
> if it didn't address some of their use cases (I note that the more recent
> WebFinger I-Ds include some SWD-ish features, such as the "resource"
> parameter -- whether that is a good thing remains to be determined).
> Although draft-jones-simple-web-discovery does not contain such an
> analysis, perhaps someone posted it to the OAUTH WG list or elsewhere, in
> which case I apologize for having missed it.
>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>

---

From: Bob Wyman <[email-masked]>
Date: Tue, 17 Apr 2012 11:06:05 -0400

On Tue, Apr 17, 2012 at 10:02 AM, Melvin Carvalho <[email-masked]>
 wrote:
> I dont know of anyone in the community (and correct me if this has
changed) that really loves acct:, or perhaps even likes the acct: idea.
Well, I like acct:. I like it precisely because it is NOT that same as
mailto:. Acct: provides me a way to identify myself or some other entity
without the identifier granting (explicitly or implicitly) any particular
capability to those who discover it. Acct: separates the functions of
identity from the mechanisms of communication. It allows one to talk about
someone without necessarily knowing how to send them mail. This is a good
thing! (Even if it irritates some spammers...)

I first worked on developing an email and "office automation" system (DEC's
ALL-IN-1) over 30 years ago and it has always bothered me that the mere act
of assuming an identity in a distributed system implicitly grants anyone
who discovers that identity the ability to gain access to my messaging
system. Acct: resolves this problem or data leak. Also, Acct: allows
services that provide value to the network without providing email services
to uniquely identify people and to provide profile services. For instance,
as far as I know, you still can't "send email" to a Twitter user. Yet,
Twitter identifiers are, in many realms, exceptionally important. I have no
idea if Twitter would want to do such a thing, but if they did want to
provide WebFinger or profile services, why in the world would we force them
to use a mailto: (which implies email support) as a means of identifying
their accounts? Would Twitter have to implement email before they could
implement WebFinger? Wouldn't it be reasonable to allow Twitter to
implement a WebFinger service that mapped from Twitter acct: identifiers to
mailto:'s on other services? (I may be acct:[email-masked] but
receive email as mailto:[email-masked]) If not, why not? The same question
holds, of course, for any number of other discussion forums, social
networks, etc. that offer services other than email. it is unreasonable to
say that only those who implement email can be identity, profile or
WebFinger providers.

> How do we get from acct: to mailto:?
To get from acct: to mailto: using WebFinger, you would have to rely on
someone telling you how. Either the mapping would be expressed in the
document itself or there would be a link to a service that does, in fact,
provide the mapping. Of course, that service could and in many cases should
impose some access control when determining who can discover the
mailto:that corresponds to a particular acct:. In fact, it would be
entirely
reasonable that there would be a one to many mapping from acct: to
mailto:and thus the acct: to mailto:mapping would be specific to a
requestor or group of requestors.
While it is useful to me to have a widely known and consistent identity, it
is not the case that everyone should know or have access to the same
mailbox when sending me messages. (Consider the extreme case of President
Obama... Certainly, we'd all like to refer to him with some consistent and
broadly known identifier (perhaps: [email-masked]") but that
doesn't mean that we should all be able to send messages to the same
mailbox that his wife or his Chief of Staff uses...)

Acct: is a good thing. We've lived with the inadequacies of using
mailto:as an identifier far too long. It is time that we separate the
mechanisms
of "identity" from the mechanisms of any of the specific services that
might rely on or leverage identity. A mailto: should be used to send mail.
An acct: should be used to name people or entities. These are distinct
functions. They should be distinct names (even when they look the same...)

Now, you know at least one person who likes acct:. Hopefully, you also
understand why.

bob wyman

On Tue, Apr 17, 2012 at 10:02 AM, Melvin Carvalho
<[email-masked]>wrote:

> The acct: URI scheme has not proved popular, imho, and has added a layer
> of complexity and confusion.  How do we get from acct: to mailto:?  When
> should you use acct: and when mailto: (the spec says acct:user@host may
> be different from mailto:user@host).  What about the forms.  How about
> linked data ecosystems that want to cross link identifiers, do they now
> have to consider both cases?
>
> I dont know of anyone in the community (and correct me if this has
> changed) that really loves acct:, or perhaps even likes the acct: idea.
> SWD has shown you can do discovery without acct: and I think that's a big
> plus.
>
>
>
>
>> BTW, I'll point out that Stephen requested that we move this discussion
>> to the Apps Discuss list, so while I'm replying here, people should follow
>> up there.  (Although I'll warn you, the traffic volume there is fierce -
>> even compared to the OAuth list at its high water marks.)
>>
>>                                -- Mike
>>

---

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: Melvin Carvalho <[email-masked]>
Date: Tue, 17 Apr 2012 21:41:52 +0200

On 17 April 2012 17:06, Bob Wyman <[email-masked]> wrote:

> On Tue, Apr 17, 2012 at 10:02 AM, Melvin Carvalho <
> [email-masked]> wrote:
> I first worked on developing an email and "office automation" system
> (DEC's ALL-IN-1) over 30 years ago and it has always bothered me that the
> mere act of assuming an identity in a distributed system implicitly grants
> anyone who discovers that identity the ability to gain access to my
> messaging system. Acct: resolves this problem or data leak. Also, Acct:
> allows services that provide value to the network without providing email
> services to uniquely identify people and to provide profile services. For
> instance, as far as I know, you still can't "send email" to a Twitter user.
> Yet, Twitter identifiers are, in many realms, exceptionally important. I
> have no idea if Twitter would want to do such a thing, but if they did want
> to provide WebFinger or profile services, why in the world would we force
> them to use a mailto: (which implies email support) as a means of
> identifying their accounts? Would Twitter have to implement email before
> they could implement WebFinger? Wouldn't it be reasonable to allow Twitter
> to implement a WebFinger service that mapped from Twitter acct: identifiers
> to mailto:'s on other services? (I may be acct:[email-masked] but
> receive email as mailto:[email-masked]) If not, why not? The same
> question holds, of course, for any number of other discussion forums,
> social networks, etc. that offer services other than email. it is
> unreasonable to say that only those who implement email can be identity,
> profile or WebFinger providers.
>
> impose some access control when determining who can discover the mailto:that corresponds to a particular acct:. In fact, it would be entirely
> reasonable that there would be a one to many mapping from acct: to mailto:and thus the acct: to mailto:mapping would be specific to a requestor or group of requestors.
> While it is useful to me to have a widely known and consistent identity,
> it is not the case that everyone should know or have access to the same
> Acct: is a good thing. We've lived with the inadequacies of using mailto:as an identifier far too long. It is time that we separate the mechanisms
> might rely on or leverage identity. A mailto: should be used to send
> mail. An acct: should be used to name people or entities. These are
> distinct functions. They should be distinct names (even when they look the
> same...)
>

Thank you for your comments.  I was unaware that anyone actually liked
acct:.  The question still remains as to whether the extra layer of
complexity justifies its inclusion.

The other thing I find confusing is: how then do you get from a
mailto:identifer, to an acct: identifier?  Is it simply string
substitution on the
scheme e.g. s/^mailto/acct/?  From what you have written above this simple
substitution seems not guaranteed to work.  So, how do you do it correctly,
if it is necessary to perform a webfinger lookup?

>
> bob wyman
>
>
> On Tue, Apr 17, 2012 at 10:02 AM, Melvin Carvalho <
> [email-masked]> wrote:
>
>>
>>
>>> From: [email-masked] [mailto:
>>> [email-masked]] On Behalf Of Peter Saint-Andre
>>> left wondering why Simple Web Discovery was developed. It appears to solve
>>> the same problem as WebFinger (which predates SWD by several years as far
>>> as I can see) in similar ways (/.well-known/ etc.), with a few tweaks and

---

From: Bob Wyman <[email-masked]>
Date: Tue, 17 Apr 2012 16:41:57 -0400

> complexity justifies its inclusion.

Distinguishing between "acct:" and "mailto:" isn't really
*adding*complexity, rather, it is just recognizing the complexity that
actually
exists in the system. We all have many identifiers. Some of them are simply
unique tokens (SSN, driver's license, passport number) and others are
actually the identifiers of proxies that are associated with us for various
purposes (i.e. email addresses, postal addresses, telephone numbers.).
Certainly, the email address is the most commonly used form of identifier,
but that is anecdotal and while it may be convenient, the exclusive
reliance on mailto: causes all sorts of problems. For instance, you may
know my mailto: but that won't always help you figure out my XMPP address.
Similarly, I may wish that you interact with me via Twitter, not email, but
if I don't want mail from you while you insist on identifying me via mailto:,
then we can't communicate even if both of us are on Twitter. There is also
the interesting problem that is caused by the fact that email addresses are
much more ephemeral than are the people who are associated with them.
Today, I work for Google, but in 10 years, or three months, who knows? If
you want to send me an email in the future, it would be really helpful for
you to have some identity such as [email-masked] (even though
LinkedIn doesn't provide email accounts...) so that you could use some
yet-to-be-implemented LInkedIn WebFinger service to figure out my email
address... Asking for acct: doesn't add complexity, it actually makes a
great number of things much simpler. The reason is that it gets the set of
identifiers that we use to more accurately model the complexity of the real
world.

>
> The other thing I find confusing is: how then do you get from a mailto:identifer, to an acct: identifier?  Is it simply string substitution on the
> scheme e.g. s/^mailto/acct/?
>
There need be no correlation between an acct: and a mailto: URI. These
things are completely orthogonal -- even though they will often appear to
be very similar. In order to determine the mailto: associated with an acct:
you would need the mapping to be explicitly stated as part of the WebFinger
document. Something like the following might do:

       "subject" : "acct:[email-masked]",
       "links" :
       [
         {
           "rel" : "http://webfinger.net/rel/
<http://webfinger.net/rel/avatar>mailto",
           "href" : "mailto:[email-masked]"
         }
       ]
     }

Of course, someone might also come up with a SWD-like system that would add
a level of indirection here. The WebFinger document would then point to an
"Acct2Mailto Mapping Service" that allowed one to authenticate and receive
an appropriate mailto: in response to a query.

>   From what you have written above this simple substitution seems not
> guaranteed to work.  So, how do you do it correctly, if it is necessary to
> perform a webfinger lookup?
>
Yes, to discover information about me, you must do a lookup on the
WebFinger discovery service.

Certainly, this could be made "simpler." But, as Einstein would have said,
the mechanism "should be as simple as possible, but no simpler." Any
attempt to make things "simpler" by obscuring the difference between an
identifier for a person and the identifier for that person's email inbox
is, I believe, an attempt to make things simpler than possible. (i.e. to
make it so simple that important information is lost and thus while some
things become more simple, others become either hard or impossible.).

>>> of complexity and confusion.  How do we get from acct: to mailto:?
>>> When should you use acct: and when mailto: (the spec says acct:user@hostmay be different from mailto:
>>> user@host).  What about the forms.  How about linked data ecosystems
>>> that want to cross link identifiers, do they now have to consider both
>>> cases?
>>>
>>> "I don’t expect everyone to like this idea. I wish I could say I love
>>> it, but I am simply content with it."
>>>

---

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: "Paul E. Jones" <[email-masked]>
Date: Tue, 17 Apr 2012 19:40:54 -0400

Derek,

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

If the document gets large, you're right that it might be an issue.  For
this reason, we introduced the "rel" parameter in the most recent WebFinger
draft.  Like HTML, this is a space-separated list of link relation types.
The idea is that the server will filter based on that list.

If you want to see it in action, you can issue a query against my ID:
$ curl https://packetizer.com/.well-known/host-meta?\
                            resource=acct%3Apaulej%40packetizer.com

or

$ curl 'https://packetizer.com/.well-known/host-meta?\
        resource=acct%3Apaulej%40packetizer.com&\
        rel=vcard+http%3A%2F%2Fwebfinger.net%2Frel%2Favatar'

The first example returns the entire XRD document.  The second example
returns only link relations of type vcard or
http://webfinger.net/rel/avatar.  To get JSON output, just replace host-meta
with host-meta.json as per RFC 6415 (or use an "Accept" header with
application/json).

Now, I'm still wondering if a resource descriptor document will ever get so
large.  It does not return information about a user, just pointers to
information.  So, do we need "rel"?  If there is definitely only a certain
set of link relations of interest, it's a way to limit the output.  I
suppose it does not hurt to introduce it; it's the value I question.  I'd
definitely like input on the utility.  Given the claims that SWD is simpler
because of the limited information returned, perhaps that lends to the
argument that it is useful.

Paul

---

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

Melvin,

On "acct:".

Humans will usually interchange an acct URI and mailto URI, probably never
using either scheme directly in practice.  That's natural and expected, if
not desired.  The intent is that we define something that looks like an
email ID, but it's not an email ID.  Some services, perhaps Twitter being
most notable, do no use email addresses.  Yet, you might have an account
there.  So, [email-masked] might be used by humans and automated systems
would convert that to acct:[email-masked].  It would not be appropriate to
use mailto: since it's not an email ID.

We did have a lot of debate about the use of "acct".  If you query my
WebFinger server, you'll see that it will work without "acct:" prefixed, as
that was a suggestion made a year or so ago.  It will inspect the input and
if it looks like an acct URI, it will assume it is.  The "acct" URI will be
returned as an alias.  However, we should always use some kind of URI scheme
to remove the guesswork.  The client can often make a very good guess as to
whether it's looking for a user account or something else.  So, let it tell
the server what it is looking for explicitly.

We need a URI scheme, because WebFinger can be used to discover all kinds of
information related to a given domain, not only user information.  It can be
used to query information about any URI, be that a web page, a user account,
device on the network, etc.  If we got rid of "acct", then we would have a
system where we sometimes use a URI scheme and sometimes we do not.  Results
might be inconsistent, as the server may not make the right guess, unless we
agreed that absence of a scheme defaults to "acct:".  However, I see no
reason for the client to be so lazy to not include "acct:".  The user might
(and probably will) exclude it, but the client code can add it.

At this point, I'd argue the "train has left the station" on "acct", too.
The current WebFinger spec exists (in part) to formally document that which
has adopted; it's not a new thing.

Paul

A couple of points:

1. JSON
=======

I think at the time webfinger was created in 2009, XML was the de facto
serialization, used in AJAX, SOAP and many other systems.  Today I'm hearing
more and more, that both developers and publishers, want to work with JSON,
rather than, having to support both xml and json.  Content negotiation also
confuses some publishers.  In my view, this is a great simplification that
webfinger can learn from SWD.

2. acct: scheme
=============

The acct: URI scheme has not proved popular, imho, and has added a layer of
complexity and confusion.  How do we get from acct: to mailto:?  When should
you use acct: and when mailto: (the spec says acct:user@host may be
different from mailto:user@host).  What about the forms.  How about linked
data ecosystems that want to cross link identifiers, do they now have to
consider both cases?  

>From the original post introducing acct:

"I don't expect everyone to like this idea. I wish I could say I love it,
but I am simply content with it."

One final side note is that this almost becomes trivial when you can do
SPARQL queries.  "void" is already registered by the W3C with IANA in
.well-known in order to discover SPARQL endpoints.  It may be overkill in
some people's eyes, but Linked Data (which predates webfinger), particularly
newer things like JSON LD, are a lot bigger than they were in 2009.  In a
few years it may become the definitive discovery mechanism anyway.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Apr 2012 01:02:13 +0100

Hi Paul,

There's also the question of privacy. Aggregated information is
always more sensitive. Sets of links, in aggregate, do leak
private information.

So it would seem fair to say that the bigger document approach
has the worse privacy problem, at least in the abstract.

If it were the case that webfinger made it noticeably harder to
partition who knows what about me, then that would be a privacy
downside, and not in the abstract, but practically. (Not a sure
showstopper, but a thing that needs attention at least.)

However, I've no idea how these are envisaged to be deployed, or
are being deployed, nor if its (intended to be) easy for a user
to create loads of different profiles/documents/whatever or not.

So - do you agree this is an issue, that webfinger aggregates
(possibly lots of) different pointers related to the same person?

And, how significant is that and are there ways to mitigate it,
for those who might care?

This aspect is essentially ignored by both swd and webfinger
drafts as far as I can see, but does seem worse with the latter
approach, at least as I understand it. (However, for a bit of
balance the string "privacy" does occur in swd, but the term
is misused when "confidentiality" was meant:-)

I do think user privacy is worth consideration regardless of
which approach is taken ultimately.

S

---

From: John Panzer <[email-masked]>
Date: Tue, 17 Apr 2012 18:20:10 -0700

It seems to me there is no difference between the two w.r.t. privacy and
aggregation of data, if you grant that webfinger's reliance on separate
http auth mechanisms is sufficient to allow access control.
On Apr 17, 2012 5:02 PM, "Stephen Farrell" <[email-masked]>
wrote:

> documents

---

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: "Paul E. Jones" <[email-masked]>
Date: Tue, 17 Apr 2012 23:14:51 -0400

Stephen,

> There's also the question of privacy. Aggregated information is always
> more sensitive. Sets of links, in aggregate, do leak private information.

Links should never leak private information.  WebFinger should provide links
only to information that a user has made publically available or that is
protected in some way.
 
> If it were the case that webfinger made it noticeably harder to partition
> who knows what about me, then that would be a privacy downside, and not in
> the abstract, but practically. (Not a sure showstopper, but a thing that
> needs attention at least.)

If your private information was shared, I would agree.  I think what you are
saying is that you are concerned with the fact that if you share information
publically in different places (e.g., a photo sharing site, a blog, a file
sharing service, a "profile" page) that bringing together pointers to all of
that in one place is a concern.  Perhaps, but there are two remedies:
1) Don't share everything publically
2) Don't put that information into your account and reported by WebFinger

As an example of (2), I choose to report certain information from my Google+
profile page that points to other sites.  I'm not so concerned with privacy,
since I know people can find anything via Google, anyway.

For those concerned with privacy, they ought not do that.  Further, if
you're so concerned about privacy, don't share anything that is publically
accessible.
 
> However, I've no idea how these are envisaged to be deployed, or are being
> deployed, nor if its (intended to be) easy for a user to create loads of
> different profiles/documents/whatever or not.

Google+ is perhaps the best example and most complete example currently.
Visit this URL:
http://webfingerclient-dclinton.appspot.com/

If you have a gmail address, put in acct:<user>@gmail.com, using your Gmail
ID.  This will return a set of link relations pointing to information you
have shared, all of which would be visible from your Google+ profile page.

If you know your Google+ profile ID, you can use that, too.  You can query
mine using this acct URI: acct:[email-masked]

I do not share certain information and Google allows me to control what
information I share.

Within an enterprise environment, I would expect a wider range of contact
information would normally be shared (business mailing address, phone
numbers, email IDs, photo, etc.)  The kinds and type of information that
would be shared via WebFinger depends on the service, but it should be
either set by some policy (e.g., corporate IT policies that are similar to
the decisions made for an internal corporate directory) or by the user
(e.g., when setting information public or not in an social networking site).
 
> So - do you agree this is an issue, that webfinger aggregates (possibly
> lots of) different pointers related to the same person?

No, because it does not go out and get information from all over the
Internet.  A WebFinger profile shares only information you want shared or as
dictated by IT policy.  A general search engine aggregates information from
all over about me and on topics over which I have no control, far more so
than WebFinger would.

> And, how significant is that and are there ways to mitigate it, for those
> who might care?

As I said, I think Google+ is a good example to follow.  I think that nearly
every piece of information on my profile page I can set to "public" or not.
Only information marked "public" is exposed via WebFinger.

Any use of WebFinger that shared more than as set by policies or by the user
would be a misuse and should be addressed by the user community of whatever
site of inconsiderate of user privacy.  I view this as no different than,
say, Google+ putting up a profile page with my private information for the
public to see.  Whether they see the information via a browser or via
WebFinger, I should have control over what's exposed.
 
> This aspect is essentially ignored by both swd and webfinger drafts as far
> as I can see, but does seem worse with the latter approach, at least as I
> understand it. (However, for a bit of balance the string "privacy" does
> occur in swd, but the term is misused when "confidentiality" was meant:-)
>
> I do think user privacy is worth consideration regardless of which
> approach is taken ultimately.

Without using the word "privacy" we do discuss that issue a bit in the
security section.  I'd be happy to add additional text or change it.  At the
end of the day, though, no standard can dictate privacy issues.  We can only
provide guidance and reminders about the importance of privacy, which does
actually vary from person to person.

Paul

---

From: Eran Hammer <[email-masked]>
Date: Wed, 18 Apr 2012 03:23:21 +0000

Practically very little if the latest Webfinger draft addition are adopted (e.g. the resource and rel query shortcuts which were originally proposed in the first OpenID Connect proposal by David Recordon and myself).

EH

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, April 17, 2012 7:55 PM
To: [email-masked]
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)

-MSK

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Mike Jones

                                                            -- Mike

b.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Apr 2012 21:24:52 -0600

Right, at that point the differences appear to be mostly about syntax,
not semantics.

On 4/17/12 9:23 PM, Eran Hammer wrote:
> Practically very little if the latest Webfinger draft addition are
> adopted (e.g. the resource and rel query shortcuts which were originally
> proposed in the first OpenID Connect proposal by David Recordon and myself).
> 
>  
> 
> EH
> 
>  
> 
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Murray S. Kucherawy
> *Sent:* Tuesday, April 17, 2012 7:55 PM
> *To:* [email-masked]
> *Cc:* [email-masked] WG
> *Subject:* Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web
> Discovery (SWD)
> 
>  
> 
> 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]>
> [mailto:[email-masked]]
> <mailto:[mailto:[email-masked]]> *On Behalf Of *Mike Jones
> *Sent:* Tuesday, April 17, 2012 4:25 PM
> *To:* Blaine Cook; Tim Bray
> *Cc:* [email-masked] <mailto:[email-masked]> WG; [email-masked]
> <mailto:[email-masked]>
> *Subject:* Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
> Discovery (SWD)
> 
>  
> 
> 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]>
> [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)
> 
>  
> 
> 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.
> 
>>> 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]>

---

From: Goix Laurent Walter <[email-masked]>
Date: Wed, 18 Apr 2012 07:07:41 +0200

+1
The acct : URI scheme is needed to give social network users a global identity in the form of 1) a URI and 2) that is compatible with a large majority of similarly formatted identifiers such as mailto:, sip:, xmpp: etc. each of them is adapted & linked to its own protocol or sphere of influence and users may or may not have the same identifier on all these URIs, although there may be deployments of service platforms that mix some of these protocols where it make sense unifying the user@domain concept (which again is all what the user sees).

The need for such a URI is also interesting for reuse within data formats for exchanging social information, eg in activity streams or opensocial specifications, where identifiers need be URIs. This goes actually beyond the scope of webfinger but clearly pertains to the sphere of a social network identifier.

walter

Da: [email-masked] [mailto:[email-masked]] Per conto di Paul E. Jones
Inviato: mercoledì 18 aprile 2012 7.00
A: 'Melvin Carvalho'; 'Mike Jones'
Cc: 'Apps Discuss'
Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

Melvin,

On "acct:"...

Humans will usually interchange an acct URI and mailto URI, probably never using either scheme directly in practice.  That's natural and expected, if not desired.  The intent is that we define something that looks like an email ID, but it's not an email ID.  Some services, perhaps Twitter being most notable, do no use email addresses.  Yet, you might have an account there.  So, [email-masked]<mailto:[email-masked]> might be used by humans and automated systems would convert that to acct:[email-masked].  It would not be appropriate to use mailto: since it's not an email ID.

We did have a lot of debate about the use of "acct".  If you query my WebFinger server, you'll see that it will work without "acct:" prefixed, as that was a suggestion made a year or so ago.  It will inspect the input and if it looks like an acct URI, it will assume it is.  The "acct" URI will be returned as an alias.  However, we should always use some kind of URI scheme to remove the guesswork.  The client can often make a very good guess as to whether it's looking for a user account or something else.  So, let it tell the server what it is looking for explicitly.

We need a URI scheme, because WebFinger can be used to discover all kinds of information related to a given domain, not only user information.  It can be used to query information about any URI, be that a web page, a user account, device on the network, etc.  If we got rid of "acct", then we would have a system where we sometimes use a URI scheme and sometimes we do not.  Results might be inconsistent, as the server may not make the right guess, unless we agreed that absence of a scheme defaults to "acct:".  However, I see no reason for the client to be so lazy to not include "acct:".  The user might (and probably will) exclude it, but the client code can add it.

At this point, I'd argue the "train has left the station" on "acct", too.  The current WebFinger spec exists (in part) to formally document that which has adopted; it's not a new thing.

Paul

A couple of points:

1. JSON
=======

I think at the time webfinger was created in 2009, XML was the de facto serialization, used in AJAX, SOAP and many other systems.  Today I'm hearing more and more, that both developers and publishers, want to work with JSON, rather than, having to support both xml and json.  Content negotiation also confuses some publishers.  In my view, this is a great simplification that webfinger can learn from SWD.

2. acct: scheme
=============

The acct: URI scheme has not proved popular, imho, and has added a layer of complexity and confusion.  How do we get from acct: to mailto:?  When should you use acct: and when mailto: (the spec says acct:user@host may be different from mailto:user@host<mailto:user@host>).  What about the forms.  How about linked data ecosystems that want to cross link identifiers, do they now have to consider both cases?

>From the original post introducing acct:

"I don't expect everyone to like this idea. I wish I could say I love it, but I am simply content with it."

I dont know of anyone in the community (and correct me if this has changed) that really loves acct:, or perhaps even likes the acct: idea.  SWD has shown you can do discovery without acct: and I think that's a big plus.

One final side note is that this almost becomes trivial when you can do SPARQL queries.  "void" is already registered by the W3C with IANA in .well-known in order to discover SPARQL endpoints.  It may be overkill in some people's eyes, but Linked Data (which predates webfinger), particularly newer things like JSON LD, are a lot bigger than they were in 2009.  In a few years it may become the definitive discovery mechanism anyway.
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.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: Eran Hammer <[email-masked]>
Date: Wed, 18 Apr 2012 05:48:02 +0000

I would have dropped XML support from the host-meta RFC but at that point it was hard to make such changes. Making such a change now with an updated RFC based on the same foundation (e.g. the document + query shortcut + LRDD relations) might be the most inclusive path forward.

EH

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Tuesday, April 17, 2012 8:25 PM
> To: Eran Hammer
> Cc: Murray S. Kucherawy; [email-masked]
> Right, at that point the differences appear to be mostly about syntax, not
> semantics.
> 
> > adopted (e.g. the resource and rel query shortcuts which were
> > originally proposed in the first OpenID Connect proposal by David Recordon
> and myself).
> >
> >
> >
> > EH
> >
> >
> >
> > *From:[email-masked] [mailto:[email-masked]] *On
> > Behalf Of *Murray S. Kucherawy
> > SWD to WebFinger, for example, in case consensus is to develop and
> > move forward with the latter?
> >
> >
> >
> > -MSK
> >
> >
> >
> > 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
> >
> >
> >
> > That's a tricky question - maybe one google can help answer? There are
> > a bunch of projects using webfinger, including status.net
> > On Fri, Apr 13, 2012 at 10:45 AM, Murray S. Kucherawy
> > <[email-masked] <mailto:[email-masked]>> wrote:
> >>> 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
> >>> 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.
> >>>

---

From: Eran Hammer <[email-masked]>
Date: Wed, 18 Apr 2012 05:50:45 +0000

I agree with John. While WF makes more information available directly, it is often in the form of templates. If you already know the resources you care about, and no authentication/authorization layer has been deployed, both expose the exact same amount of data. Both are dealing (as specified without additional layers) with public data.

EH

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Panzer
Sent: Tuesday, April 17, 2012 6:20 PM
To: Stephen Farrell
Cc: Derek Atkins; [email-masked]
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

It seems to me there is no difference between the two w.r.t. privacy and aggregation of data, if you grant that webfinger's reliance on separate http auth mechanisms is sufficient to allow access control.
On Apr 17, 2012 5:02 PM, "Stephen Farrell" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Paul,

S

On 04/18/2012 12:40 AM, Paul E. Jones wrote:
>                             resource=acct%3Apaulej%40packetizer.com<http://40packetizer.com>
>
> or
>
>         resource=acct%3Apaulej%40packetizer.com<http://40packetizer.com>&\

---

From: John Bradley <[email-masked]>
Date: Wed, 18 Apr 2012 09:13:01 +0200

I don't think there is any disagreement that without authenticating the requester, both are dealing with public info.  The only slight diffrence is that SWD forces the requester to make multiple requests to get the whole document.   The downside to SWD is that it requires a requester to make multiple requests to find multiple services.

Once we add authenticated access there are likely differing opinions on what mechinisim is easier to deploy.

From a openID connect perspective anything requiring XML parsing is going to be a non starter.
The irony of me saying that is not lost on me:)

 John B.

Sent from my iPad

On 2012-04-18, at 7:50 AM, Eran Hammer <[email-masked]> wrote:

> On Apr 17, 2012 5:02 PM, "Stephen Farrell" <[email-masked]> wrote:
> 
> Hi Paul,
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Apr 2012 09:15:35 +0100

Hiya,

On 04/18/2012 04:14 AM, Paul E. Jones wrote:
> Links should never leak private information.  

But collections of links inherently do leak some information
in that they can make correlation of one user's actions
over multiple services easier.

Those correlations can be subtle, as in e.g. the netflix
challenge case where timing information in public data
was enough.

> WebFinger should provide links

However, we know that some links will reveal more than a user
knows or wants for some users. Not that there's much we can do
about it of course.

> that in one place is a concern.  

Well s/concern/concern for some users/ - I don't want to over
emphasise this (and experience does seem to show that most
people could care less;-)

I'm fine with most else of what you say below (no point in
quibbling too much too early:-), esp. with the conclusion that
whatever is done here needs to take account of privacy issues.

I don't know if that would result in some protocol element(s)
or just some guidance and warning text, but we shouldn't
entirely rule out the former at this point.

Cheers,
S.

> Perhaps, but there are two remedies:

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 18 Apr 2012 12:04:55 +0200

On 18 April 2012 01:59, Paul E. Jones <[email-masked]> wrote:

> Melvin,****
> ** **
> On “acct:”…****
> ** **
> using either scheme directly in practice.  That’s natural and expected, if
> email ID, but it’s not an email ID.  Some services, perhaps Twitter being
> there.  So, [email-masked] might be used by humans and automated
> systems would convert that to acct:[email-masked].  It would not be
> appropriate to use mailto: since it’s not an email ID.****
>
> ** **
>
> We did have a lot of debate about the use of “acct”.  If you query my
> WebFinger server, you’ll see that it will work without “acct:” prefixed, as
> if it looks like an acct URI, it will assume it is.  The “acct” URI will be
> returned as an alias.  However, we should always use some kind of URI
> scheme to remove the guesswork.  The client can often make a very good
> guess as to whether it’s looking for a user account or something else.  So,
> let it tell the server what it is looking for explicitly.****
>
> ** **
>
> We need a URI scheme, because WebFinger can be used to discover all kinds
> of information related to a given domain, not only user information.  It
> can be used to query information about any URI, be that a web page, a user
> account, device on the network, etc.  If we got rid of “acct”, then we
> would have a system where we sometimes use a URI scheme and sometimes we do
> not.  Results might be inconsistent, as the server may not make the right
> guess, unless we agreed that absence of a scheme defaults to “acct:”.
> However, I see no reason for the client to be so lazy to not include
> “acct:”.  The user might (and probably will) exclude it, but the client
> code can add it.****
>
> ** **
>
> At this point, I’d argue the “train has left the station” on “acct”, too.
> has adopted; it’s not a new thing.
>

Paul, thank you for your explanation on lookup based on acct: (WebFinger)
vs lookup based on mailto: (SWD).

I think this is a major difference.

The original WebFinger proposal was *supposed* to give extra information
about an email address.

>From wikipedia:

"WebFinger is an Internet protocol that aims to provide information about
people by their* E-mail addresses*."

>From webfinger.org:

"Put your *email address* into the box above, click the button"

>From google code (the top hit on google):

"making *email addresses* readable again"

And perhaps most importantly from the spec, the first example:

"Assume you receive an *email *from Bob..."

However only SWD here is doing email based discovery (mailto:).  WebFinger
*now* doing acct: based discovery, which is a departure from the original
use case.

Im glad that some people have voiced support for acct:, but I still believe
that to be a minority.  I agree, that the new acct: scheme should for in
another document, rather than shoe horned into an email based discovery
system.

IMHO, it's better to solve one problem (ie email based discovery) simply
and well, than to half solve two problems (ie a new uri scheme for
identity) in a single attempt.

> ****
> ** **
> Paul****
> ** **
> anyway.****

---

From: Derek Atkins <[email-masked]>
Date: Wed, 18 Apr 2012 09:46:48 -0400

John Bradley <[email-masked]> writes:

> I don't think there is any disagreement that without authenticating the
> requester, both are dealing with public info.  The only slight diffrence is
> that SWD forces the requester to make multiple requests to get the whole
> document.   The downside to SWD is that it requires a requester to make
> multiple requests to find multiple services.

Right.

> mechinisim is easier to deploy.

I issue I would see is how you authorize access to parts of the WF
document?  How do you specify which resource links are available to
which requestors?  I don't have an answer to that.  I do think SWD might
be easier to deploy in a CRUD fashion..  But maybe there's a way to get
the best of both worlds, use something crudlike to control the
resources, but a master "index" to get the whole document (er, partial
document to which you are authorized)?

> From a openID connect perspective anything requiring XML parsing is going to

I feel this can be solved by an Accepts header, and suggesting the
server implement both XML and JSON.  The client can then request
whichever format it wants.

> The irony of me saying that is not lost on me:)

Indeed. :)

Especially since this same mechanism request came up in OAUTH and people
didn't want it there for some reason.

>  John B.

-derek

---

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:

> [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: John Panzer <[email-masked]>
Date: Wed, 18 Apr 2012 08:59:07 -0700

Last time I looked, WF takes a URI as input.  A mailto: URI is a URI.  If
someone wants to provide a look up by email address service, WF works
fine.  It just accepts more than email addresses.

What am I missing?
On Apr 18, 2012 3:05 AM, "Melvin Carvalho" <[email-masked]> wrote:

>> Humans will usually interchange an acct URI and mailto URI, probably
>> never using either scheme directly in practice.  That’s natural and
>> expected, if not desired.  The intent is that we define something that
>> looks like an email ID, but it’s not an email ID.  Some services, perhaps
>> Twitter being most notable, do no use email addresses.  Yet, you might have
>> an account there.  So, [email-masked] might be used by humans and
>> automated systems would convert that to acct:[email-masked].  It would
>> not be appropriate to use mailto: since it’s not an email ID.****
>>
>> ** **
>>
>> At this point, I’d argue the “train has left the station” on “acct”,
>> too.  The current WebFinger spec exists (in part) to formally document that
>> which has adopted; it’s not a new thing.
>>
>
>
> However only SWD here is doing email based discovery (mailto:).
> WebFinger *now* doing acct: based discovery, which is a departure from the
> original use case.
>
> Im glad that some people have voiced support for acct:, but I still
> believe that to be a minority.  I agree, that the new acct: scheme should
> for in another document, rather than shoe horned into an email based
> discovery system.
>

---

From: Bob Wyman <[email-masked]>
Date: Wed, 18 Apr 2012 13:37:57 -0400

> fine.  It just accepts more than email addresses.
Hopefully, a service that provisioned mailto addresses (i.e. a service that
provides email) would also include links to corresponding acct: URI's in
their WebFinger document and would allow users to specify acct: URI's on
services other than the one that serves the mailto: URI.
For instance, I might maintain my full WebFinger "profile" on Google, yet,
for some bizarre reason, use Yahoo! for email. I'd like people to be able
to discover my profile on Google even if I were using Yahoo!'s email
service.

What am I missing?
>>> automated systems would convert that to acct:[email-masked].  It
>>> would not be appropriate to use mailto: since it’s not an email ID.****
>>>
>>> ** **
>>>
>>> We need a URI scheme, because WebFinger can be used to discover all
>>> kinds of information related to a given domain, not only user information.
>>> It can be used to query information about any URI, be that a web page, a
>>> user account, device on the network, etc.  If we got rid of “acct”, then we

---

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

Melvin,

WebFinger does discovery on any URI.  It might be "http", "mailto", "ftp",
or "acct".  So, it's not entirely correct to say that WebFinger does not do
discovery using email addresses.  I could change my server code pretty
easily to accommodate mailto.

Use of mailto was something discussed at length.  As others pointed out, it
was not necessarily favored by all, but it was recognized to be insufficient
for some situations.  Most importantly, nobody other than us geeks knows
what the heck a "mailto" is.  But, we do recognize that social sites like
Twitter have accounts.  Thus, after the lengthy debate that took place in
several places, it was decided to go with "acct".  It actually does have a
useful purpose.  And its construction is made to look similar to "mailto" so
that the a user would just enter what they consider to be an "email"
address, including things we know are not like [email-masked].  Using
"mailto" is technically incorrect, but users never have to know or care
about that.  Behind the scenes, we use "acct".  I would personally never
show an end user "acct:[email-masked]".  Rather, I would just tell
people that their account ID is "[email-masked]".  That may or may
not be their address.  Query a Twitter account and it might return an email
address that differs (if Twitter were to share that info).

Paul

From: Melvin Carvalho [mailto:[email-masked]] 
Sent: Wednesday, April 18, 2012 6:05 AM
To: Paul E. Jones
Cc: Mike Jones; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery
(SWD)

Melvin,

On "acct:".

Humans will usually interchange an acct URI and mailto URI, probably never
using either scheme directly in practice.  That's natural and expected, if
not desired.  The intent is that we define something that looks like an
email ID, but it's not an email ID.  Some services, perhaps Twitter being
most notable, do no use email addresses.  Yet, you might have an account
there.  So, [email-masked] might be used by humans and automated systems
would convert that to acct:[email-masked] <mailto:[email-masked]>
.  It would not be appropriate to use mailto: since it's not an email ID.

Paul, thank you for your explanation on lookup based on acct: (WebFinger) vs
lookup based on mailto: (SWD).

"WebFinger is an Internet protocol that aims to provide information about
people by their E-mail addresses."

>From webfinger.org:

"Put your email address into the box above, click the button"

>From google code (the top hit on google):

"making email addresses readable again"

"Assume you receive an email from Bob..."

IMHO, it's better to solve one problem (ie email based discovery) simply and
well, than to half solve two problems (ie a new uri scheme for identity) in
a single attempt.  

Paul

A couple of points:

1. JSON
=======

2. acct: scheme
=============

---

From: Pelle Wessman <[email-masked]>
Date: Thu, 19 Apr 2012 08:52:33 +0200

While WebFinger officially requires an "acct" URI I believe almost all current implementers accept a "[email-masked]" URI as being the same as "acct:[email-masked]". Gmail.com does, StatusNet/Identi.ca does, we at Flattr does. So there is a discrepancy between the WebFinger specification and real life implementations.

Examples:

http://www.google.com/s2/webfinger/?q=[email-masked]
http://identi.ca/main/xrd?uri=[email-masked]
https://flattr.com/xrd/lrdd?uri=[email-masked]

Also, speaking from a Flattr-perspective, mail addresses and user accounts are _not_ the same thing in our system. I myself have the e-mail [email-masked] but I have the web site account [email-masked] and the web site account [email-masked] doesn't belong to me but to one of our users. I believe most web sites, at least the smaller ones, works like this - that the e-mail system and the web system is completely separated from each other and that the user identifiers in one can conflict with the identifiers in the other.

I would say that a lookup for "mailto:[email-masked]" should return info about the user behind that e-mail address (if it should return anything) but that a lookup for "[email-masked]" or "acct:[email-masked]" should always return data about the web site user and that clients should be encouraged to use "acct:" to make it clear that they want the web site's user, but that they shouldn't be required to do so.

/ Pelle

19 apr 2012 kl. 00:03 skrev Paul E. Jones:

> Melvin,
>  
> WebFinger does discovery on any URI.  It might be “http”, “mailto”, “ftp”, or “acct”.  So, it’s not entirely correct to say that WebFinger does not do discovery using email addresses.  I could change my server code pretty easily to accommodate mailto.
>  
> Use of mailto was something discussed at length.  As others pointed out, it was not necessarily favored by all, but it was recognized to be insufficient for some situations.  Most importantly, nobody other than us geeks knows what the heck a “mailto” is.  But, we do recognize that social sites like Twitter have accounts.  Thus, after the lengthy debate that took place in several places, it was decided to go with “acct”.  It actually does have a useful purpose.  And its construction is made to look similar to “mailto” so that the a user would just enter what they consider to be an “email” address, including things we know are not like [email-masked].  Using “mailto” is technically incorrect, but users never have to know or care about that.  Behind the scenes, we use “acct”.  I would personally never show an end user “acct:[email-masked]”.  Rather, I would just tell people that their account ID is “[email-masked]”.  That may or may not be their address.  Query a Twitter account and it might return an email address that differs (if Twitter were to share that info).
>  
> Paul
>  
> On “acct:”…
> Humans will usually interchange an acct URI and mailto URI, probably never using either scheme directly in practice.  That’s natural and expected, if not desired.  The intent is that we define something that looks like an email ID, but it’s not an email ID.  Some services, perhaps Twitter being most notable, do no use email addresses.  Yet, you might have an account there.  So, [email-masked] might be used by humans and automated systems would convert that to acct:[email-masked].  It would not be appropriate to use mailto: since it’s not an email ID.
>  
> We did have a lot of debate about the use of “acct”.  If you query my WebFinger server, you’ll see that it will work without “acct:” prefixed, as that was a suggestion made a year or so ago.  It will inspect the input and if it looks like an acct URI, it will assume it is.  The “acct” URI will be returned as an alias.  However, we should always use some kind of URI scheme to remove the guesswork.  The client can often make a very good guess as to whether it’s looking for a user account or something else.  So, let it tell the server what it is looking for explicitly.
>  
> We need a URI scheme, because WebFinger can be used to discover all kinds of information related to a given domain, not only user information.  It can be used to query information about any URI, be that a web page, a user account, device on the network, etc.  If we got rid of “acct”, then we would have a system where we sometimes use a URI scheme and sometimes we do not.  Results might be inconsistent, as the server may not make the right guess, unless we agreed that absence of a scheme defaults to “acct:”.  However, I see no reason for the client to be so lazy to not include “acct:”.  The user might (and probably will) exclude it, but the client code can add it.
>  
> At this point, I’d argue the “train has left the station” on “acct”, too.  The current WebFinger spec exists (in part) to formally document that which has adopted; it’s not a new thing.
> 
> 
> Paul, thank you for your explanation on lookup based on acct: (WebFinger) vs lookup based on mailto: (SWD).
> 
> The original WebFinger proposal was *supposed* to give extra information about an email address.
> 
> From wikipedia:
> 
> "WebFinger is an Internet protocol that aims to provide information about people by their E-mail addresses."
> 
> From webfinger.org:
> 
> However only SWD here is doing email based discovery (mailto:).  WebFinger *now* doing acct: based discovery, which is a departure from the original use case.  
> 
> Im glad that some people have voiced support for acct:, but I still believe that to be a minority.  I agree, that the new acct: scheme should for in another document, rather than shoe horned into an email based discovery system.  
> 
> IMHO, it's better to solve one problem (ie email based discovery) simply and well, than to half solve two problems (ie a new uri scheme for identity) in a single attempt.  
>  
>  
> Paul
>  
> A couple of points:
> 
> 1. JSON
> =======
> 
> The acct: URI scheme has not proved popular, imho, and has added a layer of complexity and confusion.  How do we get from acct: to mailto:?  When should you use acct: and when mailto: (the spec says acct:user@host may be different from mailto:user@host).  What about the forms.  How about linked data ecosystems that want to cross link identifiers, do they now have to consider both cases?  
> 
> "I don’t expect everyone to like this idea. I wish I could say I love it, but I am simply content with it."
>

---

From: Goix Laurent Walter <[email-masked]>
Date: Thu, 19 Apr 2012 15:59:34 +0200

Possibly a standard discovery mechanism should rely on some sort of URI and not a simple token string. URIs representing social network accounts are missing so far and at least this type of URI should be discoverable. Optionally I believe any type of other uri may, but with no guarantee. It may be a matter of permissions, internal db lookups and/or associations or else on the server to decide whether to provide a meaningful response to it. This is somehow already clarified in section 5 of the wf draft.

walter

Da: [email-masked] [mailto:[email-masked]] Per conto di Pelle Wessman
Inviato: giovedì 19 aprile 2012 13.53
A: Paul E.Jones
Cc: 'Apps Discuss'
Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

While WebFinger officially requires an "acct" URI I believe almost all current implementers accept a "[email-masked]<mailto:[email-masked]>" URI as being the same as "acct:[email-masked]". Gmail.com<http://Gmail.com> does, StatusNet/Identi.ca does, we at Flattr does. So there is a discrepancy between the WebFinger specification and real life implementations.

Examples:

Also, speaking from a Flattr-perspective, mail addresses and user accounts are _not_ the same thing in our system. I myself have the e-mail [email-masked]<mailto:[email-masked]> but I have the web site account [email-masked]<mailto:[email-masked]> and the web site account [email-masked]<mailto:[email-masked]> doesn't belong to me but to one of our users. I believe most web sites, at least the smaller ones, works like this - that the e-mail system and the web system is completely separated from each other and that the user identifiers in one can conflict with the identifiers in the other.

I would say that a lookup for "mailto:[email-masked]" should return info about the user behind that e-mail address (if it should return anything) but that a lookup for "[email-masked]<mailto:[email-masked]>" or "acct:[email-masked]" should always return data about the web site user and that clients should be encouraged to use "acct:" to make it clear that they want the web site's user, but that they shouldn't be required to do so.

/ Pelle

Melvin,

WebFinger does discovery on any URI.  It might be "http", "mailto", "ftp", or "acct".  So, it's not entirely correct to say that WebFinger does not do discovery using email addresses.  I could change my server code pretty easily to accommodate mailto.

Use of mailto was something discussed at length.  As others pointed out, it was not necessarily favored by all, but it was recognized to be insufficient for some situations.  Most importantly, nobody other than us geeks knows what the heck a "mailto" is.  But, we do recognize that social sites like Twitter have accounts.  Thus, after the lengthy debate that took place in several places, it was decided to go with "acct".  It actually does have a useful purpose.  And its construction is made to look similar to "mailto" so that the a user would just enter what they consider to be an "email" address, including things we know are not like [email-masked]<mailto:[email-masked]>.  Using "mailto" is technically incorrect, but users never have to know or care about that.  Behind the scenes, we use "acct".  I would personally never show an end user "acct:[email-masked]".  Rather, I would just tell people that their account ID is "[email-masked]<mailto:[email-masked]>".  That may or may not be their address.  Query a Twitter account and it might return an email address that differs (if Twitter were to share that info).

Paul

On 18 April 2012 01:59, Paul E. Jones <[email-masked]<mailto:[email-masked]>> wrote:
Melvin,

On "acct:"...

Humans will usually interchange an acct URI and mailto URI, probably never using either scheme directly in practice.  That's natural and expected, if not desired.  The intent is that we define something that looks like an email ID, but it's not an email ID.  Some services, perhaps Twitter being most notable, do no use email addresses.  Yet, you might have an account there.  So, [email-masked]<mailto:[email-masked]> might be used by humans and automated systems would convert that to acct:[email-masked]<mailto:[email-masked]>.  It would not be appropriate to use mailto: since it's not an email ID.

>From webfinger.org<http://webfinger.org>:

However only SWD here is doing email based discovery (mailto<x-msg://2/mailto>:).  WebFinger *now* doing acct: based discovery, which is a departure from the original use case.

Paul

A couple of points:

1. JSON
=======

2. acct: scheme
=============

---

From: Michiel de Jong <[email-masked]>
Date: Thu, 19 Apr 2012 16:47:43 +0200

Hi,

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

Thanks a lot for taking this initiative, and especially everyone who
has had to do concessions for this. I had thought that something like
this was impossible in standards world, but i was happy to be proved
wrong so far. I think this is a true show of the greatness of the open
web.

So about CORS headers: As one of the people who pushed for
cross-origin instead of single-origin webfinger
(https://groups.google.com/d/topic/webfinger/kfcVkqBX0tQ/discussion ),
a detail that is left out-of-scope in swd, my personal position is the
following:

- When providing webfinger/swd I will always offer CORS headers
(except when on an intranet), and I hope other people will too.
- When using webfinger/swd as a relying party i will pretty much
always need CORS headers
- It's nice if the spec informs implementers of the importance of
cross-origin http headers on what is essentially a cross-origin http
protocol by its very nature.

To give a bit of background, we use the current webfinger here:
http://www.w3.org/community/unhosted/wiki/RemoteStorage to announce
personal data services (in this case REST storage) to unhosted web
apps (also called 'client-side' or 'html5' apps). An unhosted web app
is anything that runs entirely in a browser and not on a server, so a
chrome packaged app or a w3c widget or things like a javascript-based
pacman game in a static web page. Since there is no server involved
that can do the webfinger/swd lookup, it needs to be done with a
cross-origin XHR call, hence the need for cross-origin headers.

- Having said that, the important thing in my eyes is:

    consensus in itself.

and i think no detail of the consensus (acct: or json or partial or
private or what have you) can by definition be more important than
actually reaching such consensus in the first place.

Even if it's not the details we wanted, we'll make it work somehow. We
might even need our own specific ways of using the spec for some
purposes, maybe some add-on spec or some next version, but pinning
down the syntactical compatibility of all relying parties and all
providers is important now i think.

So however you decide to merge the two specs, as long as it does
roughly what it says on the tin, we'll update to the resulting merge.

Cheers!
Michiel de Jong
(from the Unhosted project)

---

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

On 19 April 2012 15:59, Goix Laurent Walter <
[email-masked]> wrote:

>  Possibly a standard discovery mechanism should rely on some sort of URI
> and not a simple token string. URIs representing social network accounts
> are missing so far and at least this type of URI should be discoverable.
> Optionally I believe any type of other uri may, but with no guarantee. It
> may be a matter of permissions, internal db lookups and/or associations or
> else on the server to decide whether to provide a meaningful response to
> it. This is somehow already clarified in section 5 of the wf draft.
>

Why do you say "URIs representing social accounts are missing so far"?  And
if so, from which systems?

For example, Facebook has a pretty good system for representing their
accounts as URIs (open graph protocol), as does SIOC, and people like
status.net (inventor of OStatus who have a pretty good FOAF impl.) etc.
All of these use HTTP URIs as their machine representation, rather than any
proposed acct: scheme, for example.

I thought this use case is mainly relevant to the big webmail providers.

Email style discovery is missing (apart from the specific case of a public
key in GPG), so if you want a full Web sytle solution use void (already
registered with IANA).  If void is too complex, choose something simpler.
SWD seems a simpler solution, at this point, technically.  WF may have the
lead on adoption, I dont know.  Perhaps something can be learnt by each
system from each other ... e.g. the JSON vs XML discussion.  Merging the
best parts from both specs could be a great idea...

As for non mailto: URI schemes, that in itself is an interesting problem,
perhaps a big topic.  To me, xmpp: is a very interesting candidate.  Again
void can be used for this, but maybe WF/SWD is an interesting thing to
deploy.  Having a lookup for the tel: scheme would be kind of amazing ...
but is a whole problem in itself, including finding the well known
location.  HTTP discovery is really in advanced stages, with mature
deployments, under the W3C / Linked Data.  I would personally NOT encourage
acct: lookup because it's just too confusing for the average developer,
fractures identity, does not provide HTTP style 'follow your nose', and
ultimately, will probably not be a long lived identifier, given how quickly
the web identity space evolves (just my 2 cents).

I think sweet spot here is find the path of least resistance, for a really
good discovery system for email addresses.   Other schemes *could* be a
plus depending on the context, but the most compelling and useful lookup
that is filling a gap I think, is mailto: based.

****
>
> ** **
>
> walter****
>
> ** **
>
> *Da:* [email-masked] [mailto:[email-masked]]
> *Per conto di *Pelle Wessman
> *Inviato:* giovedì 19 aprile 2012 13.53
> *A:* Paul E.Jones
> *Cc:* 'Apps Discuss'
> *Oggetto:* Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
> Discovery (SWD)****
>
> ** **
>
> While WebFinger officially requires an "acct" URI I believe almost all
> current implementers accept a "[email-masked]" URI as being the same
> as "acct:[email-masked]". Gmail.com does, StatusNet/Identi.ca does,
> we at Flattr does. So there is a discrepancy between the WebFinger
> specification and real life implementations.****
>
> ** **
>
> Examples:****
>
> ** **
>
> http://www.google.com/s2/webfinger/?q=[email-masked]****
>
> http://identi.ca/main/xrd?uri=[email-masked]****
>
> https://flattr.com/xrd/lrdd?uri=[email-masked]****
>
> ** **
>
> Also, speaking from a Flattr-perspective, mail addresses and user accounts
> are _not_ the same thing in our system. I myself have the e-mail
> [email-masked] but I have the web site account [email-masked] and
> the web site account [email-masked] doesn't belong to me but to one of
> our users. I believe most web sites, at least the smaller ones, works like
> this - that the e-mail system and the web system is completely separated
> from each other and that the user identifiers in one can conflict with the
> identifiers in the other.****
>
> ** **
>
> I would say that a lookup for "mailto:[email-masked] <[email-masked]>"
> should return info about the user behind that e-mail address (if it should
> return anything) but that a lookup for "[email-masked]" or "
> acct:[email-masked]" should always return data about the web site user
> and that clients should be encouraged to use "acct:" to make it clear that
> they want the web site's user, but that they shouldn't be required to do so.
> ****
>
> ** **
>
> / Pelle****
>
> ** **
>
> ** **
>
> 19 apr 2012 kl. 00:03 skrev Paul E. Jones:****
>
>
>
> ****
>
> Melvin,****
>
>  ****
>
> WebFinger does discovery on *any* URI.  It might be “http”, “mailto”,
> “ftp”, or “acct”.  So, it’s not entirely correct to say that WebFinger does
> not do discovery using email addresses.  I could change my server code
> pretty easily to accommodate mailto.****
>
>  ****
>
> Use of mailto was something discussed at length.  As others pointed out,
> it was not necessarily favored by all, but it was recognized to be
> insufficient for some situations.  Most importantly, *nobody* other than
> us geeks knows what the heck a “mailto” is.  But, we do recognize that
> social sites like Twitter have accounts.  Thus, after the lengthy debate
> that took place in several places, it was decided to go with “acct”.  It
> actually does have a useful purpose.  And its construction is made to look
> similar to “mailto” so that the a user would just enter what they consider
> to be an “email” address, including things we know are not like
> [email-masked].  Using “mailto” is technically incorrect, but users
> never have to know or care about that.  Behind the scenes, we use “acct”.
> I would personally never show an end user “acct:[email-masked]”.
> Rather, I would just tell people that their account ID is “
> [email-masked]”.  That may or may not be their address.  Query a
> Twitter account and it might return an email address that differs (if
> Twitter were to share that info).****
>
>  ****
>
> Paul****
>
>  ****
>
> *From:* Melvin Carvalho [mailto:[email-masked]]
> *Sent:* Wednesday, April 18, 2012 6:05 AM
> *To:* Paul E. Jones
> *Cc:* Mike Jones; Apps Discuss
> Discovery (SWD)****
> On 18 April 2012 01:59, Paul E. Jones <[email-masked]> wrote:****
>
> Melvin,****
>
>  ****
>
> On “acct:”…****
>
>  ****
>
> has adopted; it’s not a new thing.****
>
>
>
> people by their* **E-mail addresses*."
>
> From webfinger.org:
>
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
> ** **
>    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.*
> *Rispetta l'ambiente. Non stampare questa
> mail se non è necessario.*
>
>

---

From: Bob Wyman <[email-masked]>
Date: Thu, 19 Apr 2012 11:26:40 -0400

On Thu, Apr 19, 2012 at 10:49 AM, Melvin Carvalho
<[email-masked]>wrote:

> Why do you say "URIs representing social accounts are missing so far"?
> And if so, from which systems?
>
> good discovery system for email addresses.
>
I'm sure that at least some existing email service providers would be very
pleased if the IETF published an RFC that effectively granted to those
email providers, by design, the effectively exclusive ability to provide
standards-based profile services on the Internet. However, I am utterly
convinced that it would be completely inappropriate to adopt a spec that
did, in fact, provide such a preference for and advantage to the providers
of email services or implementations of any other protocol.

There is no technical reason why there should be any binding or connection
between the providers of email services and the providers of profile
services. There is also, as far as I can see, no logical reason or benefit
to insist on such a binding.
We are defining protocols that need to last for many years. Even if it is
the case that today many people have unwittingly fallen into thinking of
email addresses as identifiers of people rather than of their mailboxes, we
should be concerned with "what is right" and what people should or will be
thinking in five or ten years.

*Mailto: identifies mailboxes, not people.* We need acct: in order to
better identify the people or other entities with whom mailboxes and other
resources may be associated.

>   Other schemes *could* be a plus depending on the context, but the most
> compelling and useful lookup that is filling a gap I think, is mailto:based.
>
> ****
>>
>> ** **
>>
>> walter****
>>
>> ** **
>>
>> Also, speaking from a Flattr-perspective, mail addresses and user
>> accounts are _not_ the same thing in our system. I myself have the e-mail
>> which has adopted; it’s not a new thing.****
>>
>>
>>

---

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: Christian Weiske <[email-masked]>
Date: Thu, 19 Apr 2012 18:15:33 +0200

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.

-- 
Regards/Mit freundlichen Grüßen
Christian Weiske

-=≡ Geeking around in the name of science since 1982 ≡=-

---

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: "Paul E. Jones" <[email-masked]>
Date: Thu, 19 Apr 2012 14:09:59 -0400

Pelle,

My own implementation also accepts queries that to not include "acct:".
See:

https://packetizer.com/.well-known/host-meta.json?resource=paulej@packetizer
.com

I will return "acct:[email-masked]" as an alias.

The reason this was done was because Blaine (he's quite influential) was
arguing for a while that we did not need to use a URI.  After some time, I
think there was convergence on use of "acct".  In any case, I don't think we
should look to existing implementations as the way to do it.  We need to
decide on one approach and put that into the spec.

The "mailto" URI may certainly return something, just as any other URI
might.  However, if we're making a reference to a user's account, we should
use "acct" and not "mailto".  As noted on the list before, some services may
not offer email, yet the user has an account (e.g., Twitter).  One's email
address (or set of addresses) can always be returned as data when querying a
user account.

That said, you do present a very interesting use case.  I'm surprised a
domain would allow two different users to have a name like [email-masked],
where the meaning is truly differentiated only by the URI scheme.  That must
be a source of confusion and it's not clear how WebFinger could sort that
out.  My personal opinion is that one should not tell the average user to
use mailto: or acct:, as the average user will not understand it; they
should not have to understand it.  I'm not sure what to suggest in this
case.

Paul

From: Pelle Wessman [mailto:[email-masked]] 
Sent: Thursday, April 19, 2012 2:53 AM
To: Paul E. Jones
Cc: 'Melvin Carvalho'; 'Apps Discuss'
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery
(SWD)

While WebFinger officially requires an "acct" URI I believe almost all
current implementers accept a "[email-masked]" URI as being the same as
"acct:[email-masked]". Gmail.com does, StatusNet/Identi.ca does, we at
Flattr does. So there is a discrepancy between the WebFinger specification
and real life implementations.

Examples:

Also, speaking from a Flattr-perspective, mail addresses and user accounts
are _not_ the same thing in our system. I myself have the e-mail
[email-masked] but I have the web site account [email-masked] and the
web site account [email-masked] doesn't belong to me but to one of our
users. I believe most web sites, at least the smaller ones, works like this
- that the e-mail system and the web system is completely separated from
each other and that the user identifiers in one can conflict with the
identifiers in the other.

I would say that a lookup for "mailto:[email-masked]" should return info
about the user behind that e-mail address (if it should return anything) but
that a lookup for "[email-masked]" or "acct:[email-masked]" should
always return data about the web site user and that clients should be
encouraged to use "acct:" to make it clear that they want the web site's
user, but that they shouldn't be required to do so.

/ Pelle

Melvin,

Paul

 

Melvin,

On "acct:".

However only SWD here is doing email based discovery (mailto
<x-msg://2/mailto> :).  WebFinger *now* doing acct: based discovery, which
is a departure from the original use case.  

 

Paul

A couple of points:

1. JSON
=======

2. acct: scheme
=============

---

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

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mike Jones
> 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: William Mills <[email-masked]>
Date: Thu, 19 Apr 2012 11:55:49 -0700 (PDT)

My initial proposal for discovering things about endpoints is LINK/rel, and I'll reiterate that I want to see something that can be communicated in-band for other than HTTP/S protocols.

> From: Torsten Lodderstedt <[email-masked]>
>To: Mike Jones <[email-masked]> 
>Cc: "[email-masked] WG" <[email-masked]>; Apps Discuss <[email-masked]> 
>Sent: Thursday, April 19, 2012 11:40 AM
>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, ...).
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 19 Apr 2012 16:21:14 -0400

Melvin,

We could use mailto, but mailto is for email.  That refers to one modality
of communication related to a person, but would not represent an “account”
at a domain.  Further, it would not be applicable to services like Twitter.

I would make the same argument for XMPP.  It is another communication
modality for a user at a given domain.

In general (though we’ve seen evidence of at least one exception),
[email-masked] should be an identifier reserved for a specific
account.  I use that for my XMPP address, my email address, and I would use
that to discover my OpenID URI with WebFinger.  No matter what address
scheme one starts with, acct:[email-masked] should return information
about my account and likely pointers (directly or indirectly) to all of the
other URIs I use.

The generic nature of “user@domain” is perhaps why Blaine was arguing at one
point for no scheme at all.  However, we should use a properly formed URI
since WF returns information for a URI, which then leads us to ask “what
scheme shall we use?”  Thus, “acct:” was born.  It would be legal to query
xmpp:[email-masked].  However, that may or may not return a result.
Presently, it does not.  I most definitely would not expect any WebFinger
server to consider every possible scheme under the sun.  Use of mailto: is
popular, because so many people use email.  Funny thing is that the OpenID
folks at the start were against that, arguing that email was going to die.
They were pretty insistent that OpenID URIs should look like
https://openid.packetizer.com/paulej.  And, one could use WF to query that,
too.  But, you’ll get a 404 on my server.  I do not want every possible
identifier to return a response.

IMO, “acct:” is a reasonable compromise.  It has a meaning (an account URI),
it’s communication-protocol neutral (unlike xmpp:, sip:, h323:, mailto:,
http:, etc.), and we’ve debated this at great length for at least 2 or 3
years now.  People agree “acct:” is not the most appreciated scheme, but
“mailto:” is not an appropriate since that assumes a particular protocol.
Ditto for all other protocol-specific URI schemes.

Paul

From: Melvin Carvalho [mailto:[email-masked]] 
Sent: Thursday, April 19, 2012 10:50 AM
To: Goix Laurent Walter
Cc: Pelle Wessman; Paul E.Jones; Apps Discuss
Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web
Discovery (SWD)

On 19 April 2012 15:59, Goix Laurent Walter
<[email-masked]> wrote:

Possibly a standard discovery mechanism should rely on some sort of URI and
not a simple token string. URIs representing social network accounts are
missing so far and at least this type of URI should be discoverable.
Optionally I believe any type of other uri may, but with no guarantee. It
may be a matter of permissions, internal db lookups and/or associations or
else on the server to decide whether to provide a meaningful response to it.
This is somehow already clarified in section 5 of the wf draft.

For example, Facebook has a pretty good system for representing their
accounts as URIs (open graph protocol), as does SIOC, and people like
status.net (inventor of OStatus who have a pretty good FOAF impl.) etc.  All
of these use HTTP URIs as their machine representation, rather than any
proposed acct: scheme, for example.  

As for non mailto: URI schemes, that in itself is an interesting problem,
perhaps a big topic.  To me, xmpp: is a very interesting candidate.  Again
void can be used for this, but maybe WF/SWD is an interesting thing to
deploy.  Having a lookup for the tel: scheme would be kind of amazing ...
but is a whole problem in itself, including finding the well known location.
HTTP discovery is really in advanced stages, with mature deployments, under
the W3C / Linked Data.  I would personally NOT encourage acct: lookup
because it's just too confusing for the average developer, fractures
identity, does not provide HTTP style 'follow your nose', and ultimately,
will probably not be a long lived identifier, given how quickly the web
identity space evolves (just my 2 cents).

I think sweet spot here is find the path of least resistance, for a really
good discovery system for email addresses.   Other schemes *could* be a plus
depending on the context, but the most compelling and useful lookup that is
filling a gap I think, is mailto: based.

walter

Da: [email-masked] [mailto:[email-masked]] Per
conto di Pelle Wessman
Inviato: giovedì 19 aprile 2012 13.53
A: Paul E.Jones
Cc: 'Apps Discuss'
Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery
(SWD)

While WebFinger officially requires an "acct" URI I believe almost all
current implementers accept a "[email-masked]" URI as being the same as
"acct:[email-masked] <mailto:[email-masked]> ". Gmail.com
does, StatusNet/Identi.ca does, we at Flattr does. So there is a discrepancy
between the WebFinger specification and real life implementations.

Examples:

I would say that a lookup for "mailto:[email-masked]" should return info
about the user behind that e-mail address (if it should return anything) but
that a lookup for "[email-masked]" or "acct:[email-masked]
<mailto:[email-masked]> " should always return data about the web
site user and that clients should be encouraged to use "acct:" to make it
clear that they want the web site's user, but that they shouldn't be
required to do so.

/ Pelle

Melvin,

WebFinger does discovery on any URI.  It might be “http”, “mailto”, “ftp”,
or “acct”.  So, it’s not entirely correct to say that WebFinger does not do
discovery using email addresses.  I could change my server code pretty
easily to accommodate mailto.

Use of mailto was something discussed at length.  As others pointed out, it
was not necessarily favored by all, but it was recognized to be insufficient
for some situations.  Most importantly, nobody other than us geeks knows
what the heck a “mailto” is.  But, we do recognize that social sites like
Twitter have accounts.  Thus, after the lengthy debate that took place in
several places, it was decided to go with “acct”.  It actually does have a
useful purpose.  And its construction is made to look similar to “mailto” so
that the a user would just enter what they consider to be an “email”
address, including things we know are not like [email-masked].  Using
“mailto” is technically incorrect, but users never have to know or care
about that.  Behind the scenes, we use “acct”.  I would personally never
show an end user “acct:[email-masked]
<mailto:[email-masked]> ”.  Rather, I would just tell people
that their account ID is “[email-masked]”.  That may or may not be
their address.  Query a Twitter account and it might return an email address
that differs (if Twitter were to share that info).

Paul

 

Melvin,

On “acct:”…

.  It would not be appropriate to use mailto: since it’s not an email ID.

whether it’s looking for a user account or something else.  So, let it tell

We need a URI scheme, because WebFinger can be used to discover all kinds of
information related to a given domain, not only user information.  It can be
used to query information about any URI, be that a web page, a user account,
device on the network, etc.  If we got rid of “acct”, then we would have a
system where we sometimes use a URI scheme and sometimes we do not.  Results
might be inconsistent, as the server may not make the right guess, unless we
agreed that absence of a scheme defaults to “acct:”.  However, I see no
reason for the client to be so lazy to not include “acct:”.  The user might
(and probably will) exclude it, but the client code can add it.

 

Paul

A couple of points:

1. JSON
=======

2. acct: scheme
=============

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: Bob Wyman <[email-masked]>
Date: Thu, 19 Apr 2012 16:36:06 -0400

On Thu, Apr 19, 2012 at 4:21 PM, Paul E. Jones <[email-masked]>wrote:

> modality for a user at a given domain.****
>
> ** **
>
> scheme one starts with, acct:[email-masked] should return
> information about my account and likely pointers (directly or indirectly)
> to all of the other URIs I use.****
>
> ** **
>
> The generic nature of “user@domain” is perhaps why Blaine was arguing at
> one point for no scheme at all.  However, we should use a properly formed
> URI since WF returns information for a URI, which then leads us to ask
> “what scheme shall we use?”  Thus, “acct:” was born.  It would be legal to
> query xmpp:[email-masked].  However, that may or may not return a
> result.  Presently, it does not.  I most definitely would not expect any
> WebFinger server to consider every possible scheme under the sun.
>

It would, I think, be ideal if we could expect that any domain that
provides WebFinger support would allow queries for any protocols also
supported by that domain. Thus, if a domain supports mailto:, xmpp: or
foobar: services in addition to WebFinger, it should probably support
queries for identifiers used by those services, in addition to acct:, but
for no others. In general, I think it also would be good practice to ensure
that any query for a protocol other than acct: should return a link to an
acct: identifier.

>   Use of mailto: is popular, because so many people use email.  Funny
> thing is that the OpenID folks at the start were against that, arguing that
> email was going to die.  They were pretty insistent that OpenID URIs should
> look like https://openid.packetizer.com/paulej.  And, one could use WF to
> query that, too.  But, you’ll get a 404 on my server.  I do not want every
> possible identifier to return a response.****
>
> ** **
>
> IMO, “acct:” is a reasonable compromise.  It has a meaning (an account
> URI), it’s communication-protocol neutral (unlike xmpp:, sip:, h323:,
> mailto:, http:, etc.), and we’ve debated this at great length for at
> least 2 or 3 years now.  People agree “acct:” is not the most appreciated
> scheme, but “mailto:” is not an appropriate since that assumes a
> particular protocol.  Ditto for all other protocol-specific URI schemes.**
> **
>
> ** **
>
> Paul****
>
> ** **
>
> *Sent:* Thursday, April 19, 2012 10:50 AM
> *To:* Goix Laurent Walter
> *Cc:* Pelle Wessman; Paul E.Jones; Apps Discuss
> *Subject:* Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web
> Discovery (SWD)****
>
> ** **
>
> ** **
>
> [email-masked]> wrote:****
>
> it. This is somehow already clarified in section 5 of the wf draft.****
>
>
> that is filling a gap I think, is mailto: based.****
>
>  ****
>
> walter****
>
>  ****
>
> distruzione, Grazie. ****
>
> *This e-mail and any attachments is confidential and may contain
> advise the sender by return e-mail, Thanks.* ****
>
> *Rispetta l'ambiente. Non stampare questa mail se non è necessario.* ****
>
>

---

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: Peter Saint-Andre <[email-masked]>
Date: Thu, 19 Apr 2012 15:16:07 -0600

[removing [email-masked]]

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

No new URI scheme needed, but you'd need a new URN Namespace Identifier.
Six of one, half a dozen of the other.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

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

Bob,

We could do that.  I changed my WF server code to return a response for any
URI scheme:

https://packetizer.com/.well-known/host-meta?resource=foorbar:paulej@packeti
zer.com

It returns the canonical form (the acct: URI) as an alias.

We could do as do as you suggest and return a correct response only to URI
schemes that are known.  I have no objection to that, except that I do not
want users to have to know the URI scheme to use.  I do not want the average
user to have to know or care that it’s a mailto URI or an xmpp URI or
whatever.  Users deal with identifiers like “[email-masked]”.  That’s
all they should have to worry with.  I’d rather have the WF client convert
that to a canonical form, namely acct:[email-masked] before issuing a
query. 

I do think any WF server should respond appropriately to any URI.  However,
we should remove the guesswork and I think responding to any scheme (as my
server is now doing) is not quite right.  If I visit a remote web site and
want to login using OpenID, I would enter [email-masked].  The remote
site needs to convert that to something.  What is that?  I argue that mailto
is a good assumption, but not necessarily correct.  XMPP is another good
assumption, but may also be incorrect. If we agree to a standard form
(acct:) then it removes the guesswork on the client.  I like predictability
and consistency.

Only when a client really has a specific reason for query using a different
URI like h323:[email-masked] should it do that, IMO.  But, I agree
the server should return an intelligent reply if asked.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Wyman
Sent: Thursday, April 19, 2012 4:36 PM
To: Paul E. Jones
Cc: Melvin Carvalho; Goix Laurent Walter; Apps Discuss
Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web
Discovery (SWD)

On Thu, Apr 19, 2012 at 4:21 PM, Paul E. Jones <[email-masked]>
wrote:

Melvin,

In general (though we’ve seen evidence of at least one exception),
[email-masked] should be an identifier reserved for a specific
account.  I use that for my XMPP address, my email address, and I would use
that to discover my OpenID URI with WebFinger.  No matter what address
scheme one starts with, acct:[email-masked]
<mailto:[email-masked]>  should return information about my
account and likely pointers (directly or indirectly) to all of the other
URIs I use.

The generic nature of “user@domain” is perhaps why Blaine was arguing at one
point for no scheme at all.  However, we should use a properly formed URI
since WF returns information for a URI, which then leads us to ask “what
scheme shall we use?”  Thus, “acct:” was born.  It would be legal to query
xmpp:[email-masked] <mailto:[email-masked]> .  However,
that may or may not return a result.  Presently, it does not.  I most
definitely would not expect any WebFinger server to consider every possible
scheme under the sun.

It would, I think, be ideal if we could expect that any domain that provides
WebFinger support would allow queries for any protocols also supported by
that domain. Thus, if a domain supports mailto:, xmpp: or foobar: services
in addition to WebFinger, it should probably support queries for identifiers
used by those services, in addition to acct:, but for no others. In general,
I think it also would be good practice to ensure that any query for a
protocol other than acct: should return a link to an acct: identifier.

  Use of mailto: is popular, because so many people use email.  Funny thing
is that the OpenID folks at the start were against that, arguing that email
was going to die.  They were pretty insistent that OpenID URIs should look
like https://openid.packetizer.com/paulej.  And, one could use WF to query
that, too.  But, you’ll get a 404 on my server.  I do not want every
possible identifier to return a response.

Paul

 

walter

Examples:

/ Pelle

Melvin,

Paul

 

Melvin,

On “acct:”…

 

Paul

A couple of points:

1. JSON
=======

2. acct: scheme
=============

---

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

> Six of one, half a dozen of the other.

Totally agree with you.  Tho part of standardization is deciding when
something is more like a name e.g. isbn / uuid or when something should be
a protocol e.g. xmpp / http ...

---

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: 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: "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
> 
> >> 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: Tim Bray <[email-masked]>
Date: Thu, 19 Apr 2012 22:32:41 -0700

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

---

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
> 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
> 
> > 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
> >
> >> On Thu, Apr 19, 2012 at 8:15 PM, Paul E. Jones
> >> <[email-masked]>
> >> wrote:
> >> > Mike,
> >> >
> >> >> 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: 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

> -----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
> 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
> the
> pairs), AND
> exist and
> prefer
> but so
> to
> years
> cannot
> with
> and
> single
> required
> only
> whether
> we
> no

---

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

Paul,

I would be careful in returning a positive answer to *any* type of uri and make any statement as such in the spec. I agree that from a formal perspective, anyURI should be supported as parameter value, but the server shall at least support acct:, and as bob, may answer positively to others if supported/known to that server. I would further recommends it provides back an error to those URI schemes it does not understand.

This actually opens the door to interesting capabilities such as per-URI-scheme link rel types. In other words, there may be default rel link types associated to each uri scheme (hopefully without adding much complexity on the spec itself). This may help in discovering protocol-specific endpoints of interest, ie the pop/imap endpoint serving the user's email address, etc link rel types may be prefixed/namespaced in that case so that a query to mailto: could return an additional link rel=mailto:pop for example.

Is this meaningful?
walter

Da: Paul E. Jones [mailto:[email-masked]]
Inviato: giovedì 19 aprile 2012 23.18
A: 'Bob Wyman'
Cc: 'Melvin Carvalho'; Goix Laurent Walter; 'Apps Discuss'
Oggetto: RE: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

Bob,

We could do that.  I changed my WF server code to return a response for any URI scheme:
https://packetizer.com/.well-known/host-meta?resource=foorbar:[email-masked]

We could do as do as you suggest and return a correct response only to URI schemes that are known.  I have no objection to that, except that I do not want users to have to know the URI scheme to use.  I do not want the average user to have to know or care that it's a mailto URI or an xmpp URI or whatever.  Users deal with identifiers like "[email-masked]".  That's all they should have to worry with.  I'd rather have the WF client convert that to a canonical form, namely acct:[email-masked] before issuing a query.

I do think any WF server should respond appropriately to any URI.  However, we should remove the guesswork and I think responding to any scheme (as my server is now doing) is not quite right.  If I visit a remote web site and want to login using OpenID, I would enter [email-masked]<mailto:[email-masked]>.  The remote site needs to convert that to something.  What is that?  I argue that mailto is a good assumption, but not necessarily correct.  XMPP is another good assumption, but may also be incorrect. If we agree to a standard form (acct:) then it removes the guesswork on the client.  I like predictability and consistency.

Only when a client really has a specific reason for query using a different URI like h323:[email-masked] should it do that, IMO.  But, I agree the server should return an intelligent reply if asked.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Wyman
Sent: Thursday, April 19, 2012 4:36 PM
To: Paul E. Jones
Cc: Melvin Carvalho; Goix Laurent Walter; Apps Discuss
Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

On Thu, Apr 19, 2012 at 4:21 PM, Paul E. Jones <[email-masked]<mailto:[email-masked]>> wrote:
Melvin,

We could use mailto, but mailto is for email.  That refers to one modality of communication related to a person, but would not represent an "account" at a domain.  Further, it would not be applicable to services like Twitter.

I would make the same argument for XMPP.  It is another communication modality for a user at a given domain.

In general (though we've seen evidence of at least one exception), [email-masked]<mailto:[email-masked]> should be an identifier reserved for a specific account.  I use that for my XMPP address, my email address, and I would use that to discover my OpenID URI with WebFinger.  No matter what address scheme one starts with, acct:[email-masked]<mailto:[email-masked]> should return information about my account and likely pointers (directly or indirectly) to all of the other URIs I use.

The generic nature of "user@domain" is perhaps why Blaine was arguing at one point for no scheme at all.  However, we should use a properly formed URI since WF returns information for a URI, which then leads us to ask "what scheme shall we use?"  Thus, "acct:" was born.  It would be legal to query xmpp:[email-masked]<mailto:[email-masked]>.  However, that may or may not return a result.  Presently, it does not.  I most definitely would not expect any WebFinger server to consider every possible scheme under the sun.

It would, I think, be ideal if we could expect that any domain that provides WebFinger support would allow queries for any protocols also supported by that domain. Thus, if a domain supports mailto:, xmpp: or foobar: services in addition to WebFinger, it should probably support queries for identifiers used by those services, in addition to acct:, but for no others. In general, I think it also would be good practice to ensure that any query for a protocol other than acct: should return a link to an acct: identifier.

  Use of mailto: is popular, because so many people use email.  Funny thing is that the OpenID folks at the start were against that, arguing that email was going to die.  They were pretty insistent that OpenID URIs should look like https://openid.packetizer.com/paulej.  And, one could use WF to query that, too.  But, you'll get a 404 on my server.  I do not want every possible identifier to return a response.

IMO, "acct:" is a reasonable compromise.  It has a meaning (an account URI), it's communication-protocol neutral (unlike xmpp:, sip:, h323:, mailto:, http:, etc.), and we've debated this at great length for at least 2 or 3 years now.  People agree "acct:" is not the most appreciated scheme, but "mailto:" is not an appropriate since that assumes a particular protocol.  Ditto for all other protocol-specific URI schemes.

Paul

From: Melvin Carvalho [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, April 19, 2012 10:50 AM
To: Goix Laurent Walter
Cc: Pelle Wessman; Paul E.Jones; Apps Discuss
Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

On 19 April 2012 15:59, Goix Laurent Walter <[email-masked]<mailto:[email-masked]>> wrote:
Possibly a standard discovery mechanism should rely on some sort of URI and not a simple token string. URIs representing social network accounts are missing so far and at least this type of URI should be discoverable. Optionally I believe any type of other uri may, but with no guarantee. It may be a matter of permissions, internal db lookups and/or associations or else on the server to decide whether to provide a meaningful response to it. This is somehow already clarified in section 5 of the wf draft.

Why do you say "URIs representing social accounts are missing so far"?  And if so, from which systems?

For example, Facebook has a pretty good system for representing their accounts as URIs (open graph protocol), as does SIOC, and people like status.net<http://status.net> (inventor of OStatus who have a pretty good FOAF impl.) etc.  All of these use HTTP URIs as their machine representation, rather than any proposed acct: scheme, for example.

Email style discovery is missing (apart from the specific case of a public key in GPG), so if you want a full Web sytle solution use void (already registered with IANA).  If void is too complex, choose something simpler.  SWD seems a simpler solution, at this point, technically.  WF may have the lead on adoption, I dont know.  Perhaps something can be learnt by each system from each other ... e.g. the JSON vs XML discussion.  Merging the best parts from both specs could be a great idea...

As for non mailto: URI schemes, that in itself is an interesting problem, perhaps a big topic.  To me, xmpp: is a very interesting candidate.  Again void can be used for this, but maybe WF/SWD is an interesting thing to deploy.  Having a lookup for the tel: scheme would be kind of amazing ... but is a whole problem in itself, including finding the well known location.  HTTP discovery is really in advanced stages, with mature deployments, under the W3C / Linked Data.  I would personally NOT encourage acct: lookup because it's just too confusing for the average developer, fractures identity, does not provide HTTP style 'follow your nose', and ultimately, will probably not be a long lived identifier, given how quickly the web identity space evolves (just my 2 cents).

I think sweet spot here is find the path of least resistance, for a really good discovery system for email addresses.   Other schemes *could* be a plus depending on the context, but the most compelling and useful lookup that is filling a gap I think, is mailto: based.

walter

Da: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] Per conto di Pelle Wessman
Inviato: giovedì 19 aprile 2012 13.53
A: Paul E.Jones
Cc: 'Apps Discuss'
Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

While WebFinger officially requires an "acct" URI I believe almost all current implementers accept a "[email-masked]<mailto:[email-masked]>" URI as being the same as "acct:[email-masked]<mailto:[email-masked]>". Gmail.com<http://Gmail.com> does, StatusNet/Identi.ca does, we at Flattr does. So there is a discrepancy between the WebFinger specification and real life implementations.

Examples:

I would say that a lookup for "mailto:[email-masked]" should return info about the user behind that e-mail address (if it should return anything) but that a lookup for "[email-masked]<mailto:[email-masked]>" or "acct:[email-masked]<mailto:[email-masked]>" should always return data about the web site user and that clients should be encouraged to use "acct:" to make it clear that they want the web site's user, but that they shouldn't be required to do so.

/ Pelle

Melvin,

Use of mailto was something discussed at length.  As others pointed out, it was not necessarily favored by all, but it was recognized to be insufficient for some situations.  Most importantly, nobody other than us geeks knows what the heck a "mailto" is.  But, we do recognize that social sites like Twitter have accounts.  Thus, after the lengthy debate that took place in several places, it was decided to go with "acct".  It actually does have a useful purpose.  And its construction is made to look similar to "mailto" so that the a user would just enter what they consider to be an "email" address, including things we know are not like [email-masked]<mailto:[email-masked]>.  Using "mailto" is technically incorrect, but users never have to know or care about that.  Behind the scenes, we use "acct".  I would personally never show an end user "acct:[email-masked]<mailto:[email-masked]>".  Rather, I would just tell people that their account ID is "[email-masked]<mailto:[email-masked]>".  That may or may not be their address.  Query a Twitter account and it might return an email address that differs (if Twitter were to share that info).

Paul

From: Melvin Carvalho [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, April 18, 2012 6:05 AM
To: Paul E. Jones
Cc: Mike Jones; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

On "acct:"...

However only SWD here is doing email based discovery (mailto<http://mailto>:).  WebFinger *now* doing acct: based discovery, which is a departure from the original use case.

Paul

A couple of points:

1. JSON
=======

2. acct: scheme
=============

---

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
> 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
> 
> > > 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
> > > to run XML through a sax-style parser and pull out what I want.
> > > But,
> > doing
> > > what if developers did?  It's their code.  A lot of web services
> > > have
> > been
> > > 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 ;-)
> > >
> > >> > 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.
> > >> >
> > >> > XML should be supported, but I'll note (again) that it is there
> > >> > in
> > RFC
> > >> 6415.
> 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.
> 
> 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:07:54 -0400

Walter,

Yes, I agree with you.  A SIP client, for example, might use WebFinger to
find out something about a called SIP user, with WebFinger results that
differ from if I were to query the user account for a person.  Perhaps there
might be a number of SIP-specific link relations returned.

I fully  agree with what you said.  I don’t like the code returning a
positive answer to any <scheme>:user@domain.  I made the change to highlight
out trivial it is to do, but … what’s the right thing to do?  I still
content acct: is the right thing to do when looking for information about a
person.

Paul

From: Goix Laurent Walter [mailto:[email-masked]] 
Sent: Friday, April 20, 2012 1:55 AM
To: Paul E. Jones; 'Bob Wyman'
Cc: 'Melvin Carvalho'; 'Apps Discuss'
Subject: R: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery
(SWD)

Paul,

I would be careful in returning a positive answer to *any* type of uri and
make any statement as such in the spec. I agree that from a formal
perspective, anyURI should be supported as parameter value, but the server
shall at least support acct:, and as bob, may answer positively to others if
supported/known to that server. I would further recommends it provides back
an error to those URI schemes it does not understand.

This actually opens the door to interesting capabilities such as
per-URI-scheme link rel types. In other words, there may be default rel link
types associated to each uri scheme (hopefully without adding much
complexity on the spec itself). This may help in discovering
protocol-specific endpoints of interest, ie the pop/imap endpoint serving
the user’s email address, etc link rel types may be prefixed/namespaced in
that case so that a query to mailto: could return an additional link
rel=mailto:pop for example.

Is this meaningful?

walter

Da: Paul E. Jones [mailto:[email-masked]] 
Inviato: giovedì 19 aprile 2012 23.18
A: 'Bob Wyman'
Cc: 'Melvin Carvalho'; Goix Laurent Walter; 'Apps Discuss'
Oggetto: RE: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web
Discovery (SWD)

Bob,

Paul

 

Melvin,

 

Paul

 

walter

Examples:

/ Pelle

Melvin,

Paul

 

Melvin,

On “acct:”…

 

Paul

A couple of points:

1. JSON
=======

2. acct: scheme
=============

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è
necessario.

---

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: 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: Pelle Wessman <[email-masked]>
Date: Fri, 20 Apr 2012 10:17:40 +0200

You make "updating some servers" sound easy - from eg. an OStatus perspective that's everything but easy. StatusNet and others implementations are deployed on a large amount of servers maintained by a large amount of users - often individuals hosting their own instances. As I see it it will be challenging for OStatus to support the specification this discussion results in if it that breaks backwards compatibility with all existing deployments.

I see no reason to make the resource-parameter mandatory - the benefits that comes with it makes it an obvious choice for everyone that can support it and those who can't support it can't support it even if we make the resource-parameter mandatory.

I also personally can see a need for being able to host discovery data statically from eg. an indie-web perspective - the popularity of Jekyll like systems and Jekyll hosts like GitHub Pages locks up many domains in hosts that don't support dynamic pages. To be possible to discover any information about anything on such domains you would need to support eg. static host-meta documents. A standard that can't be deployed on a regular persons site is in my opinion a bad standard.

While making it mandatory for all new deployments to support JSON I can see a problem in making new clients expect all responses to be in JSON. For backwards compatibility it would at least be good to mention the existence of XML-data in such a way that clients know that that should expect at least older WebFinger documents to give XML-responses.

/ Pelle

---

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

On 20 April 2012 16:40, Michael Thomas <[email-masked]> wrote:

> On 04/20/2012 07:17 AM, Derek Atkins wrote:
>
>> Paul,
>>
>> "Paul E. Jones"<[email-masked]>  writes:
>>
>>  Tim,
>>>
>> 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.
>>
>>
>>
> Why not MUST ASN.1 while you're at it? JSON has won in case
> you'all haven't noticed it.
>

+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: Daniel Renfer <[email-masked]>
Date: Fri, 20 Apr 2012 11:08:34 -0400

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

On Fri, Apr 20, 2012 at 7:17 AM, Derek Atkins <[email-masked]> wrote:
> Paul,
>
> "Paul E. Jones" <[email-masked]> writes:
>
>> Tim,
>>
> <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: 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: Derek Atkins <[email-masked]>
Date: Fri, 20 Apr 2012 10:17:51 -0400

Paul,

<OAUTH Chair Hat>

</OAUTH Char Hat>

-derek

---

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

Mike

---

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: Eran Hammer <[email-masked]>
Date: Fri, 20 Apr 2012 15:25:07 +0000

The general approach I've taken with host-meta was to provide a framework and allow each application to make its choices regarding what's required and what's optional. For example, an application using host-meta must decide if it requires the use of TLS or supports both HTTP and HTTPS. It may require the availability of JSON, and as the WebFinger draft proposes, it may require or make available additional query parameters.

There is a LOT of history here. Previous versions included document signatures, a new host: URI scheme, use of XRD <Subject>, a wide range of LRDD processing rules, multiple links support for LRDD (HTTP headers, HTML markup, host-meta), processing priority rules, and on and on. This approach did not work out because the requirements of the different communities involved were just too wide.

For example, Google did not want to require TLS for host-meta and wanted to develop a document signature method instead for using it with OpenID because (at least at the time), TLS was limited to requiring an IP address per hosted domain they provide this service to, and they just could not get that many IP addresses for all these TLS certificates. The various working groups involved spent about 6 months just developing this approach but eventually it was abandoned due to lack of interest and other ongoing projects.

The point is, host-meta by itself is useless. It is only a basic layer for building actual discovery on top, as discovery requires decisions about what information is actually being requests and the security/privacy attributes required.

This process of profiling can be done very specifically (e.g. OpenID Connect can use host-meta by requiring TLS, JSON, and the resource and rel parameters - and can do that today) or very broadly (e.g. the approach taken by the current WebFinger draft to define additional general purpose features).

I'm not expecting everyone here to have the full background on this work, but hopefully people can appreciate that this has been worked on for over 5 years in multiple standards bodies (IETF, OASIS, W3C), has been extensively reviewed and discussed by the W3C TAG, etc. We can obviously reach other compromises now than were desired/possible a year ago when this work was finalized, but let's not kid ourselves that reaching consensus on another compromise will be easy (or even possible).

EH

> [email-masked]] On Behalf Of Daniel Renfer
> Sent: Friday, April 20, 2012 8:09 AM
> To: William Mills
> 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.
> 
> > 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: 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: Eran Hammer <[email-masked]>
Date: Fri, 20 Apr 2012 19:07:06 +0000

It does unless updated.

6415 guarantees that if you send a request to /host-meta you will get XML unless you ask for JSON, in which case you MIGHT get JSON.
It also defined /host-meta.json which MIGHT be supported and if it is, guarantees JSON.

Simplest way forward is to focus on /host-meta.json as 6415 says nothing about having to support /host-meta if you offer /host-meta.json... this is a bit of a hack but will work. IOW, protocols that want only JSON as required can mandate /host-meta.json support and allow /host-meta support.

This means XML clients will need to understand JSON in case the server doesn't offer the XML default location.

EH

> [email-masked]] On Behalf Of John Bradley
> Sent: Friday, April 20, 2012 11:53 AM
> To: Gonzalo Salgueiro
> Cc: Derek Atkins; [email-masked]; Apps Discuss

---

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

---

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:17:21 -0400

Pelle,

> You make "updating some servers" sound easy - from eg. an OStatus
> perspective that's everything but easy. StatusNet and others
> implementations are deployed on a large amount of servers maintained by a
> large amount of users - often individuals hosting their own instances. As
> I see it it will be challenging for OStatus to support the specification
> this discussion results in if it that breaks backwards compatibility with
> all existing deployments.
> 
> I see no reason to make the resource-parameter mandatory - the benefits
> that comes with it makes it an obvious choice for everyone that can
> support it and those who can't support it can't support it even if we make
> the resource-parameter mandatory.

If the OStatus clients continued to operate as they do, then a change in the
spec would not cause an immediate breakage.  Servers could be updated with
time and clients could follow subsequently.  Is that possible?

In any case, I appreciate the challenge, which is why we made this parameter
optional to support.  That addresses both the forward- and backward-
compatibility issues.

> I also personally can see a need for being able to host discovery data
> statically from eg. an indie-web perspective - the popularity of Jekyll
> like systems and Jekyll hosts like GitHub Pages locks up many domains in
> hosts that don't support dynamic pages. To be possible to discover any
> information about anything on such domains you would need to support eg.
> static host-meta documents. A standard that can't be deployed on a regular
> persons site is in my opinion a bad standard.

If the site is so small, it could ignore what's requested and return a
static page.  The "subject" would not match, but the client should take note
of that.

How would you host LRDD on a static site?  Something like this:
http://example.com/lrdd/acct:[email-masked]

That would certainly work and you are right that the "resource" parameter
would prevent that from working.
 
> While making it mandatory for all new deployments to support JSON I can
> see a problem in making new clients expect all responses to be in JSON.
> For backwards compatibility it would at least be good to mention the
> existence of XML-data in such a way that clients know that that should
> expect at least older WebFinger documents to give XML-responses.

I'm still favorable to requiring both XML and JSON on the server.  If this
were extremely complex documents, I might by sympathetic to a concern over
complexity.  But, supporting both formats is fairly simple.

Paul

---

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
> 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.
> 
> 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.
> 
> > change that breaks backward-compatibility.  This is one change that
> would do that.
> >
> > Paul
> >

---

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

> 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)<http://www.itu.int/ITU-T/asn1/xml/xer.htm>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: 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:
>>
>>
>>
> defined the XML Encoding Rules (XER) a few years back.
>

---

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: Melvin Carvalho <[email-masked]>
Date: Sun, 22 Apr 2012 05:09:54 +0200

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

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

if acct: is to become a new protocol for the internet , I request that it
should be fully documented, and available for review

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

---

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: "Paul E. Jones" <[email-masked]>
Date: Sat, 21 Apr 2012 23:51:06 -0400

Melvin,

The acct: URI scheme is not a new protocol, but just a scheme that refers to user accounts. It is documented in the WebFinger draft.

Paul

---

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