Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side

From: Melvin Carvalho <[email-masked]>
Date: Sat, 1 Jun 2013 16:40:11 +0200

On 31 May 2013 02:08, Paul E. Jones <[email-masked]> wrote:

> Melvin,****
>
> ** **
>
> Thanks for bringing that text forward.****
>
> ** **
>
> All,****
>
> ** **
>
> So, the first part of the issue seems to be one of “what URI do I use and
> why?”  The answer really is “whatever URI you have”.****
>
> ** **
>
> The second paragraph goes into one area where I understand why one might
> be confused.  In the example, the client queried the acct URI and just
> fabricated that by taking the email address (of the form user@domain) and
> turning that into an account URI.  That said, I don’t know I would call
> that a semantic gap.  Humans do this.  If you see user@domain, you assume
> it’s an email address.  Likewise, Microsoft Word will do the same.  For WF,
> there is the suggestion that it’s safe to assume it can be converted to
> acct:user@domain.  That might be a faulty assumption, but so might
> assuming that user@domain is an email address if there is no URI scheme.
>  Even if there were, the intent of the acct URI is to represent user
> accounts and the expectation is that the form would “look like” email
> addresses.  So, what can we add to the document to make this clearer?
>

There are heuristics, but heuristics tend to associate user@host with
mailto.  I think it valid to ask the question "how would a machine make
this determination?"

Ideally you may need a preflight lookup service that will tell a machine
which identifier to use.  And this relation would also be confirmed when
you got back the JRD record.  Or you need an out of band (ie in the spec)
translation service that can be coded into a client.  From the perspective
of a machine, another possibility is to have it cached.

I'm not a huge fan of the acct: URI scheme.  It seems to me that

/.well-known/acct/bob

Would work just as well. Now consider a hypothetical scenario that we had
these two "synonyms" for a "user account".  How can a machine know what to
translate a mailto: address into.

I would prefer to use mailto URIs instead as an 'indirect identifier', and
not need acct: at all.  I know some say this is problematic because
semantically an email address does not have a name or avatar etc.  However,
you can also make the argument, that an account is not a user, either.  My
bank account has a name, but it is not *my* name, yet I own my bank
account.  In truth the distinction between user vs agent vs account vs
email vs representation tends to be something of a grey area.  It amount to
striking the balance between semantic rectitude, interoperability and ease
of use.

Just my 2 cents...

> **
>
> ** **
>
> The third paragraph goes into use of different URI schemes and the
> expected results returned.  WebFinger should not prescribing exactly what
> gets returned for any particular URI.  The intent of the WF spec is to
> define the tool used to perform a query and the syntax of the query and
> response.  However, how one actually get configuration information or what
> information should be returned for a given URI should be defined elsewhere,
> IMO.  We expect that account-related information about a user will be
> returned if one queries with an acct URI.  We do not want to define what is
> returned for mailto: or xmpp: or other.  We might use it for
> configuration or we may never use those with WebFinger.  I would say that
> should be the scope of another spec.****
>
> ** **
>
> The example in 3.4 is intended to be mysterious.  It has been a struggle
> to provide examples, as some do not like abstract examples and some do not
> like concrete examples.  This is one of the more abstract examples; the
> device URI scheme does not even exist. The intent of the example is just to
> show that WF can be used for a range of things, but the syntax is
> consistent.  Why a particular URI scheme is used and exactly what links,
> properties, etc. will be returned should be defined elsewhere.****
>
> ** **
>
> The last paragraph asks why the resource part is a URI at all.  That was
> debated at length a few years ago when the acct URI scheme was discussed.
>  Blaine Cook was one in favor of using no scheme at all.  However, there
> was a desire to be able to issue a WF query for different URIs, because
> different URIs might return different responses.  I appreciate the
> immediate question is “what would be different”, but I don’t think it’s the
> WF spec that should dictate what gets returned for any particular URI.  The
> OpenID specs Mike referenced is a good example that prescribes what to
> expect using a given URI scheme.  The OpenID Connect spec can utilize
> either the acct URI or an http URI.****
>
> ** **
>
> What words can we introduce that will help to resolve this issue?****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* Melvin Carvalho [mailto:[email-masked]]
> *Sent:* Thursday, May 30, 2013 4:27 AM
> *To:* Paul E. Jones
> *Cc:* [email-masked]; salvatore loreto;
> webfinger
> *Subject:* Re: [webfinger] [appsawg] #12: Semantic gap for the client side
> ****
>
> ** **
>
> ** **
>
> ** **
>
> On 30 May 2013 04:12, Paul E. Jones <[email-masked]> wrote:****
>
> Folks,
>
> Sal noted that we have several DISCUSS points to cover.  He referred us to
> this page:
> http://tools.ietf.org/wg/appsawg/trac/report/1
>
> Let's take this first item.  I'll start with #12 here.
>
> The idea with Host-Meta and, hence, WebFinger, is that a client that wants
> to know anything about a given URI, it takes the URI and issues a query as
> per RFC 6415 or per the WebFinger spec.  The intent was to allow any URI,
> though if one is looking for information about a user's account, the
> recommendation is to use the 'acct' URI, since it is intended to represent
> an account owned by a user, versus other URIs like mailto or http.
>
> There may be multiple versions of the story that led us here, but the
> problem some were trying to address was the use of http URIs for OpenID.
>  It was hard for users to use.  Users are accustomed to user@domain form
> of addresses, but then there was the question of what URI to use for those.
>  The mailto URI could work, but it was not appropriate if one were querying
> for a user on Twitter, for example.  That and other reasons led to the
> creation of the 'acct' URI scheme.  And, so we recommend the use of that
> URI scheme in Section 4.5 of the draft.  However, a client most certainly
> could query for information about a user using any type of URI.  For
> example, this is valid:
> $ curl
> https://packetizer.com/.well-known/webfinger?resource=https%3A%2F%2Fwww.packetizer.com
>
> The expected result is JRD that describes the queried resource.  The most
> useful resource probably is the 'acct' URI today.  The acct URI would
> return a JRD that describes the account.
>
> So, what is the semantic gap, exactly?  What text can we add to make this
> clearer without confining WF to being useful only for 'acct' URIs?****
>
> ** **
>
> The full text may help here:
>
> [[
> There appears to be a big giant semantic gap for the client side of this
> protocol. I can find nothing in the document that indicates to the client
> how it shall determine what sort of URI to use is the resource part of
> the query or what the semantics of any given URI are supposed to be. I
> suspect that the semantics are so underspecified that there could not
> possibly be interoperable implementations without lots of out-of-band
> information.
>
> The first example provides a mapping from an email address (or perhaps a
> mailto URI; that's not clear) to an acct URI, but neither the example nor
> anything in the rest of the document gives any clue why you would choose
> to query an "acct" URI based on the contents of an email message. I think
> the assumption is that if there is an email address, there must be some
> sort of "account" associated with it, and therefore querying the host on
> the RHS of the "@" for that account will get some interesting
> information. But I don't see any reason to choose an "acct" scheme over
> "mailto" or "smtp" or "email" or "foobar"; as far as I can tell, the
> choice is semantics-free.
>
> Reading the above alongside 3.3 makes me all the more suspicious: In 3.3
> (also mentioned in 4.5), a "mailto" URI gets you configuration
> information for all email configuration parameters. Does an "acct" URI
> get you configuration information for email *and* xmpp *and* sip *and*
> calendaring *and* all other configuration information (since you are no
> longer asking for a particular protocol, but rather the general account
> information), or do you only get "information" about the person and not
> their account? (I might also insert privacy and security worries here,
> but see Stephen's DISCUSS regarding that.) How can the client know what
> sort of information it can ask for and how to get it? And for that
> matter, how does the server tell what information to pass back? You'd
> think there would be a hint about this in 4.3, but "rel" only seems to
> provide for the client to request those things that the client already
> knows about it. In particular, there appears to be no way to say, "Give
> me user provided information, but not config information" or "Give me
> config information, but not blog entries".
>
> I find the semantics for "device" in 3.4 all-the-more mysterious. As far
> as I can tell, this URI scheme simply means, "Give me all of the
> information for the entire host."
>
> Again, the semantics of all of these interactions seem so underspecified
> that I don't understand how interoperation is supposed to happen.
>
> This also leaves me with the question about why the resource query part
> is a URI at all. It seems to me that the resource you are asking about is
> not a URI (or URN) at all; it's simply an identifier for an entity that
> the particular host knows about. Given that, why not pass a simple
> identifier? (See http://datatracker.ietf.org/doc/draft-ietf-radext-nai/
> for example.) If the scheme is not providing any particular semantics
> about the response, I see no reason to provide the scheme. If more
> semantics (beyond rel) are needed, another parameter indicating the type
> of identifier being used seems much more appropriate than using a URI
> scheme.
> ]]****
>
>  ****
>
>
> Paul
>
> > -----Original Message-----
> > From: appsawg issue tracker [mailto:[email-masked]
> ]
> > Sent: Wednesday, May 29, 2013 3:21 AM
> > To: [email-masked];
> > [email-masked]
> > Cc: [email-masked]
> > Subject: [appsawg] #12: Semantic gap for the client side
> >
> > #12: Semantic gap for the client side
> >
> >  the document should clarify how  the client will be able to determine
> > what
> >  sort of URI to use is the resource part of the query or
> >  what the semantics of any given URI are supposed to be.
> >
> >  (This a Discuss, present in the IESG Evaluation Record)
> >
> > --
> >
> -------------------------------------+------------------------------------
> > -
> >  Reporter:                           |      Owner:  draft-ietf-appsawg-
> >   [email-masked]      |  [email-masked]
> >      Type:  defect                   |     Status:  new
> >  Priority:  blocker                  |  Milestone:
> > Component:  webfinger                |    Version:
> >  Severity:  -                        |   Keywords:
> >
> -------------------------------------+------------------------------------
> > -
> >
> > Ticket URL: <http://tools.ietf.org/wg/appsawg/trac/ticket/12>
> > appsawg <http://tools.ietf.org/appsawg/>
>
>
> _______________________________________________
> webfinger mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webfinger****
>
> ** **
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 03 Jun 2013 20:34:24 -0400

On Sat, 1 Jun 2013 16:40:11 +0200, Melvin Carvalho wrote:
> On 31 May 2013 02:08, Paul E. Jones wrote:
[snip]
>> scheme. Even if there were, the intent of the acct URI is to
>> represent user accounts and the expectation is that the form would
>> "look like" email addresses. So, what can we add to the
>> document to make this clearer?
>
> mailto. I think it valid to ask the question "how would a machine
> make this determination?"

Would not not be valid to simply take the email address on the From 
line and attach acct: to the front of it?  In practice, I would expect 
that is what people will do.  That's what I've seen already in practice, 
so I feel fairly confident in saying that.

Granted, it will not always work.  There may not be an "account" 
associated with the email address.  And some email addresses might be 
unusual.  (Any uucp still in use today?)  But, a quick inspection to see 
if it looks like the usual user@domain is fairly common.

> Ideally you may need a preflight lookup service that will tell a
> machine which identifier to use. And this relation would also be
> confirmed when you got back the JRD record. Or you need an out of
> band (ie in the spec) translation service that can be coded into a
> client. From the perspective of a machine, another possibility is to
> have it cached.

I would think that is only true if one wants to map the email address 
to some other identifier that is very different (e.g., mapping 
[email-masked] to [email-masked]).

> Im not a huge fan of the acct: URI scheme. It seems to me that
>
> /.well-known/acct/bob
>
> Would work just as well. Now consider a hypothetical scenario that we
> had these two "synonyms" for a "user account". How can a machine
> know what to translate a mailto: address into.

Do note that the example we're discussing is an email message.  It does 
not contain a "mailto:" URI.  Rather, it contains an email address, 
usually of the form user@domain.  (Also, it is just an example, not 
something intended to be normative.)

Using the above well-known URI would certainly work vs. the WebFinger 
URI.  But then any well-known URI could work.

The reason for using WebFinger is because this is the WebFinger service 
and we want to have the ability to give it any URI and the server return 
a JRD for that URI.

> I would prefer to use mailto URIs instead as an indirect identifier,
> and not need acct: at all. I know some say this is problematic
> because semantically an email address does not have a name or avatar
> etc. However, you can also make the argument, that an account is not
> a user, either. My bank account has a name, but it is not *my* name,
> yet I own my bank account. In truth the distinction between user vs
> agent vs account vs email vs representation tends to be something of 
> a
> grey area. It amount to striking the balance between semantic
> rectitude, interoperability and ease of use.

In truth, one could use any kind of identifier.  One reason (and 
perhaps not the only reason) for not using a mailto URI is that it is 
not appropriate for some services.  I mentioned this before, but it's 
worth saying again: Twitter user accounts do not have email addresses 
associated with them.  The same used to be true of Facebook, but no 
longer.  There was a desire to have some kind of account identifier that 
identifies an account at a service.  Other kinds of services include 
photo sharing web sites or even identity management sites.  I have an 
account at Amazon and many other places where I do not have email 
service.  The "acct" URI can be used to identify the account.  In the 
case of your bank account, perhaps your account might be 
acct:<acct#>@<bankname.com>.  (I doubt a bank would ever implement WF 
for customer accounts, and surely would not advise it.  Nonetheless, 
that's the form of the identifier I would expect to be used against a WF 
service at the bank.

So, where does this leave us?  We should either decide to make some 
small changes to the example to get rid of the discussion point about 
the email address and the leap to the acct URI, or remove the example 
entirely.  I rather like having the example, as it helps illustrate the 
utility of WF.  But, we can remove it or change it.  I don't want to go 
back and rehash the necessity of the acct URI scheme.

Paul

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 5 Jun 2013 19:13:55 +0200

On 4 June 2013 02:34, Paul E. Jones <[email-masked]> wrote:

> Would not not be valid to simply take the email address on the From line
> and attach acct: to the front of it?  In practice, I would expect that is
> what people will do.  That's what I've seen already in practice, so I feel
> fairly confident in saying that.
>
> unusual.  (Any uucp still in use today?)  But, a quick inspection to see if
> it looks like the usual user@domain is fairly common.
>
>
> I would think that is only true if one wants to map the email address to
> some other identifier that is very different (e.g., mapping
> Using the above well-known URI would certainly work vs. the WebFinger URI.
>  But then any well-known URI could work.
>
> and we want to have the ability to give it any URI and the server return a
> JRD for that URI.
>
>> agent vs account vs email vs representation tends to be something of a
> In truth, one could use any kind of identifier.  One reason (and perhaps
> not the only reason) for not using a mailto URI is that it is not
> appropriate for some services.  I mentioned this before, but it's worth
> saying again: Twitter user accounts do not have email addresses associated
> with them.  The same used to be true of Facebook, but no longer.  There was
> a desire to have some kind of account identifier that identifies an account
> at a service.  Other kinds of services include photo sharing web sites or
> even identity management sites.  I have an account at Amazon and many other
> places where I do not have email service.  The "acct" URI can be used to
> identify the account.  In the case of your bank account, perhaps your
> account might be acct:<acct#>@<bankname.com>.  (I doubt a bank would ever
> implement WF for customer accounts, and surely would not advise it.
>  Nonetheless, that's the form of the identifier I would expect to be used
> against a WF service at the bank.
>
> So, where does this leave us?  We should either decide to make some small
> changes to the example to get rid of the discussion point about the email
> address and the leap to the acct URI, or remove the example entirely.  I
> rather like having the example, as it helps illustrate the utility of WF.
>  But, we can remove it or change it.  I don't want to go back and rehash
> the necessity of the acct URI scheme.
>

Given that the original motivation for Web Finger was the email use case
(in fact in it's first drafts it was the ONLY use case), IMHO, keeping that
example would be important.

I'm unsure how to word it, but it seems to me that user@host is most
naturally translated to mailto:user@host as a URI.  Now this will either be
the primary key of the data structure (subject) or the foreign key to the
data structure (object).  The webfinger query is asking something like
either 1) give me all key / values pairs where mailto:user@host is the
subject OR 2) give me all "sibling" key value pairs where
mailto:user@hostis the email value, in which case the subject could be
anything including
an acct: URI.

---

From: Pete Resnick <[email-masked]>
Date: Thu, 13 Jun 2013 10:09:32 -0500

Sorry for not hopping into this conversation much earlier. I'll try to 
be very responsive so we can make some progress on this.

On 5/30/13 7:08 PM, Paul E. Jones wrote:
>
> So, the first part of the issue seems to be one of "what URI do I use 
> and why?"  The answer really is "whatever URI you have".
>
> The second paragraph goes into one area where I understand why one 
> might be confused.  In the example, the client queried the acct URI 
> and just fabricated that by taking the email address (of the form 
> user@domain) and turning that into an account URI.  That said, I don't 
> know I would call that a semantic gap.  Humans do this.  If you see 
> user@domain, you assume it's an email address.
>

OK, so I'm the client. I've got an email address. What URI do I use if I 
want email configuration parameters? Do I use mailto:? Or smtp:? Or 
pop:? Does acct: get me email configuration parameters along with 
personal information about the user?

I also think that email address is also a jabber ID (or maybe I'm 
wondering if it is)? Do I do a second query with jabber:user@domain? Or 
will acct: get me back jabber account info?

My real concern here is that this document gives me no help as to what 
kind of information I get back from any given URI, and gives me no help 
in how to choose the right URI scheme to get me back the info I want. 
The assumption appears to be, "You client get to choose whatever URI 
scheme you think is interesting, and if I server have information about 
that URI, I'll tell you what it is. Otherwise, try again." That's not 
interoperable.

I can come up with grand re-designs to address my concerns, but if 
you've got answers to the above questions, maybe that will help us 
figure out some easy stuff to add (an IANA registry, a "how to figure 
out URI semantics" section, etc.) that will make this protocol make sense.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 Jun 2013 22:04:34 -0400

Pete,

On Thu, 13 Jun 2013 10:09:32 -0500, Pete Resnick wrote:
> Sorry for not hopping into this conversation much earlier. I'll
> try to be very responsive so we can make some progress on this.
> 
>> So, the first part of the issue seems to be one of "what URI do I
>> use and why?" The answer really is "whatever URI you have".
>>
>> user@domain) and turning that into an account URI. That said, I
>> don't know I would call that a semantic gap. Humans do this. If you
>> see user@domain, you assume it's an email address.
> 
>  OK, so I'm the client. I've got an email address. What URI do I use
> if I want email configuration parameters? Do I use mailto:? Or smtp:?
> Or pop:? Does acct: get me email configuration parameters along with

You're assuming WF defines how to provision an email client.  It doesn't.
There is an example in the text, but it is merely an example to illustrate
the kinds of things WF can be used.

In order for WF to be used in provisioning an email client, the specific
procedures would need to be spelled out in a document somewhere. 

> wondering if it is)? Do I do a second query with jabber:user@domain?
> Or will acct: get me back jabber account info?

Each URI queried might return the same or different information.  The
specifications that rely on WebFinger would state explicitly what URI to
use.  As an example, the OpenID Connect specs state that
acct:[email-masked] would be used to issue a WebFinger query.

In general, it is expected that if one is looking for account information
related to an identifier in user@domain form, then acct: would be used.  For
example, if you are looking for a picture of me that I publish, a list of
mew ATOM feeds, or whatever else I might publish, that would be used.
Obviously, this does not necessarily get all information about me, nor might
the querying entity even be querying the correct account.

But we all have lots of accounts in lots of places.  We have picked on
Twitter a number of times, because it's an good example of why "acct:" is
needed.  There are no email addresses there.  So, let's say you know my
Twitter ID paul_e_jones.  You could issue a query to
acct:[email-masked].  At least that's the intent.  What might be
returned is whatever I publish via my account on the Twitter service.

The acct URI is not tied to any particular protocol, but is intended to
relate to a user account at the specified domain.

But, we do want to allow any URI to be queried.  It's even possible to query
the URI "http://www.packetizer.com/" via WebFinger.  That's a web page, not
a person or account.  Querying for that will return whatever information the
server wants to return.  This is what one could do with RFC 6415, so the
same functionality is carried forward.
 
>  My real concern here is that this document gives me no help as to
> what kind of information I get back from any given URI, and gives me
> no help in how to choose the right URI scheme to get me back the info
> I want. The assumption appears to be, "You client get to choose
> whatever URI scheme you think is interesting, and if I server have
> information about that URI, I'll tell you what it is. Otherwise, try
> again." That's not interoperable.

You are entirely right that it does not give guidance, except for "acct".
If you are querying for information related to a user's account at some
domain, then use "acct".

If I want to know information about a particular URI, query for that URI.

The problem is not knowing what URI to query, but knowing what set of links
will be returned as a result of using a particular URI.  That's not defined,
because we cannot specify in this spec how to provision an email client or
what kind of information one might want returned if querying for a Jabber
ID.

The expectation is that other documents would define link relations.  In
fact, we already have a laundry list of those that folks want to define.  As
those are defined and registered in the existing registry, then the URI to
use with WF would also be defined.  They might all end up under "acct" as
OpenID Connect specifies.  However, if the aggsrv group elects to use
WebFinger to bootstrap the discovery process, they might specify the use of
mailto: to get links to aggsrv documents.
 
> out URI semantics" section, etc.) that will make this protocol make

I'm certainly willing to add more text to help make the point, but I'm not
sure what to add where.  Basically, use various URIs and the expected set of
links relation types (and, thus, links) is intended to be defined in other
specifications, not the base WebFinger spec.

Paul

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 14 Jun 2013 08:59:04 +0200

On Thu, Jun 13, 2013 at 10:04:34PM -0400,
 Paul E. Jones <[email-masked]> wrote 
 a message of 110 lines which said:

> You're assuming WF defines how to provision an email client.  It
> doesn't.  There is an example in the text, but it is merely an
> example

And a bad one since we already have RFC 6186. IMHO, this example,
which is quite confusing and was already mentioned several times with
misunderstanding, should be deleted.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 14 Jun 2013 03:09:44 -0400

Stephane,

> misunderstanding, should be deleted.

We do have that, but that is one solution.  The new Working Group aggsrv
will be defining something that is HTTP-based.  WF may or may not be used
for that effort.

Just because another mechanism exists and new mechanisms are in the works
does not mean this is a bad example.  If there is confusion, then we should
clarify the confusion.  I don't mind adding a statement that makes it
explicitly clear that the example is not an IETF-approved means of
provisioning an email client.

With the examples in the spec, there have been comments ranging from "the
example is too abstract" to "the example looks like it could be real" (the
case with this email provisioning example).  We could remove all examples,
but I don't think that's helpful to the reader in understanding how the
protocol works.

Paul

---

From: Pete Resnick <[email-masked]>
Date: Fri, 14 Jun 2013 09:18:52 -0500

> the kinds of things WF can be used.

I am starting to think that the examples are part of the problem. And I 

> procedures would need to be spelled out in a document somewhere.

So WF is not a protocol itself. It's a framework. You can't actually use 
WF without having a separate document specifying:

1. The semantics of what a particular URI scheme means for a query. 
(E.g., acct: means give me personal information associated with this 
string, mailto: means give me email configuration information associated 
with this email identifier, jabber: means give me jabber configuration 
information associated with this identifier, http: means give me the 
personal author information for this particular web page, etc.)

2. The JRD name/value pairs that can be returned for any given URI scheme.

Now, I am worried that you will disagree with my description of the 
particular protocol document above because you will say, "For any URI 
scheme, the WF server could return *any* information. So, for a jabber: 
URI, it could return either jabber configuration information or personal 
information about the jabber ID or anything else. For an acct: URI, it 
could return personal information, or it could return account 
configuration information." If that's the intent, then *that's* the 
semantic gap and a failing of WF: If the client can't find any 
documentation about how it can get back particular information, the 
protocol is a mere guessing game and not useful *except in closed 
environments with out-of-band agreements*. If you have a closed 
environment with an out of band agreement, you don't need a standard.

> acct:[email-masked] would be used to issue a WebFinger query.

That's the part that scares me. Let's say I'm not using OpenID Connect. 
Let's saying I'm using the "PeteID Info" protocol. Do I get to redefine 
what an acct: URI returns? If so, that's completely non-interoperable.

> We have picked on
> acct:[email-masked].
>    

Just a note for the particular example: I'd query "acct:paul_e_jones", 
not "acct:[email-masked]", wouldn't I? Twitter doesn't use a 
domain portion in its account IDs, does it?

> same functionality is carried forward.

So are you saying that the semantics of querying for an http: URI are 
identical to querying for host meta data for the URI? Then you don't 
mean that it "will return whatever information the server wants to 
return"; it's going to return a particular set of data as defined by 
6415. But I suspect that's not what you're saying.

> [...]
> will be returned as a result of using a particular URI.
>    

Neither this document nor the acct: URI document gives any guidance 
about what set of links will be returned for the acct: URI. The 
semantics of querying for the acct: URI are never defined. It gives 
examples using the acct: URI, but it never actually defines what links 
or other properties an acct: URI can return.

I'm perfectly OK for this document to be clear that other documents will 
define the specific semantics of what particular URI schemes will return 
and for what purpose they ought to be queried, but everything in the 
document and everything that I've heard said indicates that those 
documents will do no such thing. They are not going to lock down the 
semantics for the client; the semantics of what gets returned is going 
to be entirely up to the server and only known to the client through 
out-of-band means.

> OpenID Connect specifies.

So how do I as a client know whether I am doing an OpenID Connect query 
or a PeteID Info query? I can't tell via the URI scheme?

Something is missing in this protocol.

pr

---

From: 'Stephane Bortzmeyer' <[email-masked]>
Date: Fri, 14 Jun 2013 16:27:35 +0200

On Fri, Jun 14, 2013 at 03:09:44AM -0400,
 Paul E. Jones <[email-masked]> wrote 
 a message of 31 lines which said:

> I don't mind adding a statement that makes it explicitly clear that
> the example is not an IETF-approved means of provisioning an email
> client.

Then saying clearly that the example is not an example of present and
actual use: it's brainstorming about what WebFinger could do in the
future.
 
> With the examples in the spec, there have been comments ranging from
> "the example is too abstract" to "the example looks like it could be
> real" (the case with this email provisioning example).  We could
> remove all examples,

Indeed, some of the examples are wrong. In -14:

> Locating a User's Blog

OK for me (except the erroneous "en-us" that I already mentioned here)

> Identity Provider Discovery for OpenID Connect

OK for me (I assume not OK for Pete Resnick because there are no
details about the possible "rel" in the query and the possible links
in the response)

> Auto-Configuration of Email Clients

Useless and dangerous. 

> Retrieving Device Information

Dangerous, for security reasons, as mentioned in the IESG ballot

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 14 Jun 2013 10:33:55 -0400

Hi Pete,

> what an acct: URI returns? If so, that's completely non-interoperable.

That touches one of the concerns I had about using webfinger for aggregated 
service discovery. In most cases aggsrv clients are only going to care 
about a aggsrv details/links so they ought to have a way to request that 
only those links be returned in the webfinger response. So adding some 
query parameters that would let the client list the specific pieces of 
information it wants would solve that, and may well address Pete's specific 
point above.

-- 
Cyrus Daboo

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 14 Jun 2013 16:33:35 +0200

On Fri, Jun 14, 2013 at 09:18:52AM -0500,
 Pete Resnick <[email-masked]> wrote 
 a message of 126 lines which said:

> I am starting to think that the examples are part of the problem.

I agree that some of the examples describe, not what WebFinger does
today, but what it may do in a bright future where many other things
will have been specified. The last two in -14 are specially
problematic.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 14 Jun 2013 12:19:27 -0400

Pete,

> > You're assuming WF defines how to provision an email client.  It
doesn't.
> personal author information for this particular web page, etc.)

I would agree with most of this, except that I do view this as more than
just a framework document.  If I want to get a set of links related to a
given URI, the document tells you exactly how to do that.  It also documents
in detail the exact format of the query and the response.

What is not detailed (and to your point) is what link types would one expect
to receive in the returned JRD document when querying the server with any
particular URI.  That will have to be defined somewhere else.  Many have
been defined already inside and outside the IETF.  The OpenID Connect
document is one example.  I have assembled a list of ones in use that I know
about and there are some that folks do intend to standardize in the IETF.
 
> Now, I am worried that you will disagree with my description of the

Moi?  Disagree? :-)

> environment with an out of band agreement, you don't need a standard.

It is true that a WF server could return any information for a given URI
scheme, but that's because we have not specified anything that is to be
expected for any given URI, except "acct:".

We do not want to have the ambiguity you describe.  Devices and applications
should not play guessing games.  If one wishes to retrieve information about
a user's account, then "acct:" is to be used and that is recommended in the
WF spec.  This is one reason that OpenID Connect uses the acct URI scheme.
Those folks then defined the particular link type that the client should
look for.  Folks are planning to specify use of acct for other link types,
including pointers to a user's picture, blog, etc.

Until there is a specification that says exactly what information to expect
if one were to use mailto: or jabber:, then one should not use those URIs.
That said, we do want WebFinger to accommodate those or any URI type.  This
is to align with RFC 6415, but also because there might be something useful
defined for other URIs in the future, just as we're seeing 'acct' take
shape.

> what an acct: URI returns? If so, that's completely non-interoperable.

No, but you might define a new link type.  Consider the example in the
OpenID Connect spec:
http://openid.net/specs/openid-connect-discovery-1_0.html#EmailSyntax

The "rel" value is defined by the OpenID Foundation.  You may also define
your own "rel" value.  When a client queries a WF server for
acct:[email-masked], any number of link types might be returned.
Some might be defined within the IETF and some might be defined outside the
IETF.

However, a client will know exactly what it is looking for and would ignore
link type is does not understand.  Any client that implements PeteID would
be looking for a specific link type defined in your protocol spec.

You can query my account to see some example link types:
$ curl
https://packetizer.com/.well-known/webfinger?resource=acct:paulej@packetizer
.com

You'll see some "rel" values that are in the webfinger.net domain and some
in the packetizer.com domain.  What folks want to do is specify some of
those in the IETF.  For example, say you want my vcard.  Presently, nothing
tells you how to find it.  My server will return a "rel" of
"http://packetizer.com/rel/businesscard" and a type of "text/vcard".  To be
useful, this would need to be standardized.  There is an intent to
standardize this one and others (blog, avatar, profile-page, etc.).

> domain portion in its account IDs, does it?

The 'acct' URI scheme is of this form:

acctURI      =  "acct" ":" userpart "@" host

(See draft-ietf-appsawg-acct-uri-04.)

The intent was that the host portion would always be present.  Twitter does
not use email addresses, so you never see "@twitter.com".  But, if querying
for account information at twitter.com for user paul_e_jones, the URI would
be constructed as I showed it.

> identical to querying for host meta data for the URI?

Correct.

> Then you don't

I would say yes to this, except that RFC 6415 does not really define the set
of link types that will be returned, either.  It specifies the protocol to
use, but the specification of the link types was intended to be detailed
elsewhere.  RFC 6415 gives examples of "copyright" and "author" link types.
Those are defined outside the context of RFC 6415, but used as examples in
that spec.  Those are valid link types to be returned if one were to query
using the URI of a web page.  Still, nothing concretely says those are to be
expected or may appear in the response.  (I'm not sure if anyone uses those
in practice, either, with WebFinger or RFC 6415.)
 
> or other properties an acct: URI can return.

That's true.  The OpenID Connect spec is one that does define one link type.
There are some other groups that have defined some link types outside the
IETF.  But as I mentioned above, the intent is to standardize some link
types.  That plan has been on the table waiting for WF to get done.  Even if
that document never sees the light of day, other groups are specifying link
types for use with WF. (I would personally like to see a set of agreed
standard link types, though.)

> to be entirely up to the server and only known to the client through

It was definitely not the intent that clients would be guessing as to how to
perform a query.  If a client is looking for my avatar, for example, the
client needs to know exactly what URI to use and what link type to look for.
That should be spelled out in the document that describes the link type.

Any words you want to suggest for the WF spec to make that abundantly clear,
I'm happy to introduce.

> or a PeteID Info query? I can't tell via the URI scheme?

As the client, you know whether you're trying to do OpenID or PeteID.  I
don't see that as an issue.  If you are an OpenID Connect client, then you
follow the procedures as specified in the above referenced spec, looking for
acct:user@domain and for a specific link type.
 
> Something is missing in this protocol.

I believe it's the specification of link types, properties, etc.  Those
would be spelled out by other specifications.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 14 Jun 2013 12:28:10 -0400

Stephane,

> actual use: it's brainstorming about what WebFinger could do in the

Yes and no.  The intent is to give the reader a crisp idea of how the
protocol works.

The email configuration example, IMO, was a good one, because it illustrated
how to use those elements of the syntax so well that somebody on the list
remarked that "this could really work" or something like that.
 
> OK for me (except the erroneous "en-us" that I already mentioned here)

What's the issue with "en-us"?

> details about the possible "rel" in the query and the possible links

That's defined in the OpenID Connect discovery specification.
 
> > Auto-Configuration of Email Clients

I'm pretty sure nobody will get murdered over this, so I question the claim
it's dangerous.  The fact that is looks so real it could work suggests is
properly demonstrates in a practical example how WF could be used.  The fact
that this is not the way we will provision an email client is a separate
issue and I don't mind adding text -- whatever you suggest -- to make it
even more clear that this is only an example for illustrative purposes.

> Dangerous, for security reasons, as mentioned in the IESG ballot

I really don't understand how this could have any security implications
since the example is entirely bogus.  Again, this is only an example, and
it's an example that will not even work since "device:" is not defined.  If
we defined "device:" tomorrow, it's still an example that would require a
different spec to spell out the link types and properties.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 14 Jun 2013 12:34:54 -0400

Cyrus,

> information it wants would solve that, and may well address Pete's

There is a way for the client to request only the links of interest.  That's
done via the "rel" parameter in WebFinger, which may appear multiple times,
each with a different value.

Compare these two:
$ curl
https://packetizer.com/.well-known/webfinger?resource=acct:paulej@packetizer
.com
$ curl
'https://packetizer.com/.well-known/webfinger?resource=acct:paulej@packetize
r.com&rel=http://packetizer.com/rel/blog&rel=http://webfinger.net/rel/avatar
'

The first returns the entire JRD.  The second returns only the link types of
interest.  Even if additional link types are returned, those can safely be
ignored by the client.

For aggsrv, we may not even want to use 'acct', but perhaps
protocol-specific URIs (e.g., 'smtp' or 'jabber').  Whatever is used, the
aggsrv specs would specify the URI scheme(s) to use, along with the link
types, properties, etc.

Paul

---

From: Barry Leiba <[email-masked]>
Date: Fri, 14 Jun 2013 18:59:14 +0200

> 2. The JRD name/value pairs that can be returned for any given URI scheme.

...

> Neither this document nor the acct: URI document gives any guidance about
> what set of links will be returned for the acct: URI. The semantics of
> querying for the acct: URI are never defined. It gives examples using the
> acct: URI, but it never actually defines what links or other properties an
> acct: URI can return.
>

Let me stick something in here:

There are two ways we can get interoperability from this.  One is to
explicitly specify everything that might be returned from a particular
query.  Another is to make sure that what gets returned is self-defining.
 The latter is the point of link relations -- the link relation tells you
what the link means, so the recipient knows whether it understands this
type or not, and, if it understands it, knows what its semantics are and
what to do with it.

Barry

---

From: Pete Resnick <[email-masked]>
Date: Fri, 14 Jun 2013 13:00:42 -0500

> expected for any given URI, except "acct:".

Where in the document (or in the -acct-uri document) does it specify 
what is to be expected for the acct: URI? I can find nothing in the 
-webfinger document that is outside of an example, and certainly nothing 
with a MUST or a SHOULD or even a MAY, describing what is to be expected 
for a query on an acct: URI. Your statement appears to be incorrect.

> WF spec.

Where????

If the document said anything like this, I would not be pushing back. Do 
you think that section 4.5 is saying that? That's not nearly what I 
would call a specification.

> defined for other URIs in the future, just as we're seeing 'acct' take

The document should say that the semantics of URI queries will be 
defined in other documents. The document should probably also set up an 
IANA registry of URI queries that can be used along with their specific 
meanings and pointers to the documents defining these things.

Again, right now the client is flying completely blind.

> No, but you might define a new link type.
>    

Let's skip link types. Let's talk about properties. What properties can 
I expect to get back for the acct: URI webfinger query? Where is this 
documented? For instance, how do I ask for the full name of the person 
associated with the account? Other than the example in 4.4.3, I find 
nothing in this document or the -acct-uri document that tells me what I 
can expect, or how I can even ask the question.

> For example, say you want my vcard.  Presently, nothing

That's my point. You haven't specified the use of the acct: URI at all 
in this document. You're leaving it for a future standard. You haven't 
even set up a registry of URIs that can be used for webfinger that would 
contain pointers to the standard that would define the semantics. There 
is not enough in this document to do anything interoperable with.

> be constructed as I showed it.

How am I (as a client) supposed to know that? I got a Twitter 
identifier. It doesn't have a domain portion. How am I supposed to 
figure out that I'm supposed to put "@twitter.com" after it? Why not 
"@twitter.net" or "@twitter.id"? Why not leave it out and use a URI that 
doesn't require a domain name? Where is this defined? (I *hope* not 
every service that wants to provide account information has to 
separately publish it's own rules for forming the query!)

Skipping down...

> Any words you want to suggest for the WF spec to make that abundantly clear,

I can work on that if desired. Tim Bray's idea would also make it 
abundantly clear. But what would also address the issue is some text 
which explicitly says, "This is a framework. How to query for particular 
purposes is in other documents. This document defines a registry where 
you can find the different use cases." And if you want, register 
"acct:". And give it some expected semantics.

I think Tim is correct: This document is trying to boil the ocean. The 
problem is it's only providing instructions on what to do after the 
entire ocean is in the pot and the fire is going. It's short a few 
pieces of info.

pr

---

From: Pete Resnick <[email-masked]>
Date: Fri, 14 Jun 2013 13:01:58 -0500

On 6/14/13 11:59 AM, Barry Leiba wrote:

> query.  Another is to make sure that what gets returned is 
> self-defining.  The latter is the point of link relations -- the link 
> relation tells you what the link means, so the recipient knows whether 
> it understands this type or not, and, if it understands it, knows what 
> its semantics are and what to do with it.

That will make the response interoperable. It does not help me make the 
query.

There is no problem in this protocol on the server side. The problem is 
on the client side. There is no specification of what the client is 
supposed to do.

pr

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 14 Jun 2013 12:40:14 -0600

> can expect, or how I can even ask the question.

WebFinger enables the client to say "please tell me more about this
account", not "please tell me the full name of the person associated
with this account". The response might include a pointer to a URI for
the vCard, and if you retrieve that vCard it will probably contain the
full name. But the WebFinger server just gives you pointers to data, not
the data itself. Or so it seems to me.

Peter

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

---

From: Evan Prodromou <[email-masked]>
Date: Fri, 14 Jun 2013 21:08:12 -0400

On 13-06-14 02:01 PM, Pete Resnick wrote:
>> explicitly specify everything that might be returned from a 
>> particular query. Another is to make sure that what gets returned is 
>> relation tells you what the link means, so the recipient knows 
>> whether it understands this type or not, and, if it understands it, 
>> knows what its semantics are and what to do with it.
>
> That will make the response interoperable. It does not help me make 
> the query.
>
> There is no problem in this protocol on the server side. The problem 
> is on the client side. There is no specification of what the client is 
> supposed to do.
>
> pr
>
  * If you want to know the URL of the profile page of the user with
    account "evan" on server "e14n.com",
  * request the JRD at
    https://e14n.com/.well-known/webfinger?resource=acct:[email-masked],
  * and find the link with rel "http://webfinger.net/rel/profile-page".

What you do with that information (show it to someone, store the HTML in 
a database, whatever) is out of scope.

Just as a point: Webfinger is already in use; the older LRDD version has 
been in use for years. It's great for finding endpoints for various APIs 
on different servers for different users.

-Evan

---

From: Evan Prodromou <[email-masked]>
Date: Fri, 14 Jun 2013 21:20:50 -0400

I feel like this discussion is stalemated and I'd like to ask for it to 
be closed.

What's the next step for coming to a decision here?

-Evan

---

From: Mike Jones <[email-masked]>
Date: Sat, 15 Jun 2013 01:43:15 +0000

I've just read about two weeks of WebFinger mail (catching up after vacation) have the following observations on how we might make progress towards closing the issues being discussed.

1.  Explicitly state that WebFinger is a framework and that the information to be returned for specific "rel" link relation types for specific kinds of URIs is outside the scope of the specification, but is intended to be defined by other specifications.

2.  We could establish a registry indexed by "rel" link relation values pointing to documents that define this information.  For instance, we could then register the "rel" value "http://openid.net/specs/connect/1.0/issuer" and point it to http://openid.net/specs/openid-connect-discovery-1_0.html, which defines the meaning of that link relation.  Other link relation definitions could then also use that registry.

3.  Explicitly state that the link relation types that will be returned from server when no "rel" parameter is used is entirely dependent upon the services supported by that host, and that, in the general case, clients must be prepared for the response to be the empty set for any particular resource.

4.  Since people are finding the examples problematic, we could remove them, or possibly only keep the OpenID Connect one, which is concrete and being used in practice.  Or in fact, we could add a second OpenID Connect example - so that there's one with the resource being a URL and another with the resource using e-mail address syntax.  We could also bring over the apparently-innocuous "copyright" and "author" examples from RFC 6415, if those would cause people less consternation.  But the device and e-mail examples seem to be generating more heat than light.

5.  We could remove all references to and discussion of the acct: URI, since WebFinger actually has no dependency upon it.  Other specifications can still specify that it be used in particular contexts with WebFinger, as OpenID Connect does.

I realize that the examples provide more context for developers but if they're standing between us and finishing the spec it would be better for them to go.  Likewise, if acct: is standing between us and finishing, it should go too.

I'll close by saying that I believe that WebFinger does one simple thing very well - enabling querying about a resource at a host, optionally narrowing the query to a particular kind of information of interest.  Like OAuth, this protocol is both incredibly simple and incredibly powerful.  Like OAuth, particular applications of WebFinger will define particular syntax to be used in requests and responses that meets the needs of those applications.

Let's focus our energies on deciding what the best next steps are to finish in a timely manner.

				Cheers,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pete Resnick
Sent: Friday, June 14, 2013 11:02 AM
To: Barry Leiba
Cc: salvatore loreto; Paul E. Jones; Melvin Carvalho; [email-masked]; webfinger
Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side

> its semantics are and what to do with it.

That will make the response interoperable. It does not help me make the query.

There is no problem in this protocol on the server side. The problem is on the client side. There is no specification of what the client is supposed to do.

pr

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 14 Jun 2013 21:47:10 -0400

Pete,

> for a query on an acct: URI. Your statement appears to be incorrect.

The WF spec only says if you want information about an account, the acct URI
should be used.  Now, what gets returned when querying an acct URI is not
specified.  The plan is that one might be able to get OpenID Connect info,
an avatar, a vcard, etc.  The OpenID Connect draft already spells that out.
The others are to be specified in other drafts.

Over time, there may be any number of new link relation types defined and
intended for use with WebFinger.  There are already requirements in place
for that registry to have an RFC spelling things out.
 
> > a user's account, then "acct:" is to be used and that is recommended in

Uhm...

> would call a specification.

Yeah... section 4.5.  WF does not dictate the use of any URI.  The group
just wanted to encourage use of "acct" when querying a user's account at
whatever service.  Much of this relates to social network accounts, but
certainly not limited to those.

What URI is queried to get whatever information via WebFinger would be
specified elsewhere.
 
> meanings and pointers to the documents defining these things.

I'll insert whatever words you want.  Exactly what would you like me to put
where?

I'm not quite sure how we'd construct this registry.  There is already the
link relation registry.  Now, which of those are for use in HTTP?  Which
ones for use in ATOM?  Are there separate registries for those two
protocols?

> Again, right now the client is flying completely blind.

Presently, that's largely true.  However, there are community-defined link
relation types out there that people just started using.  Those would be
returned if one queries a user's account URI.  OpenID Connect has a formal
spec that explains how an OpenID Connect client would perform a query.
There is intent by a few folks to define a few other link relation types for
use with WebFinger once the base spec is done.  Those would also spell out
that queries would be via the acct URI.

The aggsrv group, if it elected to use WebFinger, would specify use of acct
or perhaps smtp, jabber, etc.  That's really their call and would be
documented in their specs.

> can expect, or how I can even ask the question.

The WF spec allows for URI-level properties and link-level properties.
Property types are fully-qualified URIs and the property name (URI) and
value would be defined in whatever specification wanted to define them.

As Peter responded, the user's name is likely to be found via a link that
points to a vcard or xcard.  I would personally like to define properties at
the account level that are the user's names, but it would be redundant with
the vcard.  Still, it might be useful so that a client would not have to
grab a vcard and parse it.  This would be a subject for discussion at some
later point.

For now, properties are not defined anywhere.  The mail server configuration
example shows the intent of properties.  If there was a spec that defined
how to provision an email client, it would detail the link relation type,
specify the URI scheme to use to query for the JRD, and define any
properties associated with that link type.
 
> is not enough in this document to do anything interoperable with.

The acct URI scheme is recommended.  It used to be a part of this draft,
even, but it was pulled out separately since there was belief it has broader
value.

Any URI may be used with WebFinger, so what would the registry tell us?

Let's say I am writing a blogging application and I want names and faces of
users visiting the blog to appear on the site.  As part of the registration,
I might ask you to enter the account identifier from which to get your name
and face.  This might be your email address, your facebook ID, Twitter ID,
or whatever.  The client I write on the blog site create a URI in the form
acct:user@domain, because the two pieces of information are link relation
types defined for use with the acct URI.  I know this, because there will be
an RFC written that says so.  The link relation types in that to-be-written
document are registered with IANA, just as link relation types for HTTP and
ATOM are registered there.

>From the "acct" URI spec:
   Thus a particular 'acct' URI is formed by setting the "user" portion
   to the user's account name at the service provider and by setting the
"host"
   portion to the DNS domain name of the service provider.

That's the guidance.  I assume Twitter's account IDs do not start with an
'@'.  It's not present in the URI when visiting a person's Twitter page.
Thus, I assume the '@' is just a means of indicating to the Twitter platform
that the following is an account ID vs. regular text when tweeting.

Given the above and then yet-to-be-written RFCs (that defines the link
relation types) to perform WF queries, it should be possible to visit the
blog I described above, tell it your Twitter account (and I'd even write it
to be smart enough to auto-convert @paul_e_jones to
acct:[email-masked]), and it would query Twitter to see if it can
get your name and picture.
 
> "acct:". And give it some expected semantics.

Is HTTP (RFC 2616) a framework document?  It defines the syntax of the
request and response, but does not define the payload.  WebFinger is
more-or-less the same thing: it defines that the protocol on the wire looks
like going to the server and from the server.  But, it does not define what
a client will query for, nor does it define the payload to be returned.

The link relation registry already exists, so I'm not sure we need another
registry.  We may need a registry for properties, though, if any properties
are to be defined with an IETF-specified URI.  Presently, we've not
discussed defining any properties (aside from my mention above).

In any case, I'll add whatever text you think is appropriate.

> entire ocean is in the pot and the fire is going. It's short a few

Allowing use of any URI is not boiling the ocean, IMO.  The only issue, I
think, is that there are missing pieces.  The WF spec does not describe what
set of links is returned if one issues a query for any particular URI.  That
was deliberately left for other specifications.

I would venture to guess that the 'acct' URI will be what is used most with
WF, because of the interest from social networking circles.  However, we
didn't want to limit it to that one URI scheme.  Some have stated, for
example, that they'd like to use the 'tel' URI with WF.  I can appreciate
how one might use that as a means of determining which of several ENUM
registries to query, for example.  Some are already using http URIs with
WebFinger, too (e.g.
http://openid.net/specs/openid-connect-discovery-1_0.html#URLSyntax).  And
if we want to know the author of a web page, querying a server and passing
the URI of the web page could result in returning a link with the "author"
link relation type, perhaps also a "copyright", etc.  (Those are examples in
RFC 6415.)

I think boiling the ocean would have been defining all these use cases in
the WF spec.  We did not want to do that.  Instead, we define the base
protocol and then other specs define how to use WF to get certain
information.

Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 14 Jun 2013 21:06:49 -0600

On 6/14/13 7:43 PM, Mike Jones wrote:
> I've just read about two weeks of WebFinger mail (catching up after
> vacation) 

You're a good man. :-)

> have the following observations on how we might make
> progress towards closing the issues being discussed.
> 
> 1.  Explicitly state that WebFinger is a framework and that the
> information to be returned for specific "rel" link relation types for
> specific kinds of URIs is outside the scope of the specification, but
> is intended to be defined by other specifications.

Agreed.

> 2.  We could establish a registry indexed by "rel" link relation
> values pointing to documents that define this information.  For
> instance, we could then register the "rel" value
> "http://openid.net/specs/connect/1.0/issuer" and point it to
> http://openid.net/specs/openid-connect-discovery-1_0.html, which
> defines the meaning of that link relation.  Other link relation
> definitions could then also use that registry.

That seems quite sensible.

> 3.  Explicitly state that the link relation types that will be
> returned from server when no "rel" parameter is used is entirely
> dependent upon the services supported by that host, and that, in the
> general case, clients must be prepared for the response to be the
> empty set for any particular resource.

I'll need to think about that more.

> 4.  Since people are finding the examples problematic, we could
> remove them, or possibly only keep the OpenID Connect one, which is
> concrete and being used in practice.  Or in fact, we could add a
> second OpenID Connect example - so that there's one with the resource
> being a URL and another with the resource using e-mail address
> syntax.  We could also bring over the apparently-innocuous
> "copyright" and "author" examples from RFC 6415, if those would cause
> people less consternation.  But the device and e-mail examples seem
> to be generating more heat than light.

Yes.

> 5.  We could remove all references to and discussion of the acct:
> URI, since WebFinger actually has no dependency upon it. 

I think that would be helpful, because in the off-list email threads
with the IESG there is a lot of confusion about the meaning of an acct
URI, and much of that confusion stems from (I think) a misunderstanding
of WebFinger's relationship to acct URIs and a conflation of the
semantic meaning that comes from WebFinger and the semantic meaning that
comes from acct URIs.

> Other
> specifications can still specify that it be used in particular
> contexts with WebFinger, as OpenID Connect does.

Right.

> I realize that the examples provide more context for developers but
> if they're standing between us and finishing the spec it would be
> better for them to go. 

I'd hate to remove examples that are helpful, but if some of the
examples are confusing (and I think they are, because they are
speculative rather than examples that reflect existing usage or
WebFinger-based applications) then let's remove them.

> Likewise, if acct: is standing between us and
> finishing, it should go too.

Works for me. I didn't conceive of acct URIs, I'm just trying to get
them documented properly.

> I'll close by saying that I believe that WebFinger does one simple
> thing very well - enabling querying about a resource at a host,
> optionally narrowing the query to a particular kind of information of
> interest.  Like OAuth, this protocol is both incredibly simple and
> incredibly powerful.  Like OAuth, particular applications of
> WebFinger will define particular syntax to be used in requests and
> responses that meets the needs of those applications.
> 

Thanks for the productive message. Let's get this done.

Peter

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

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Sat, 15 Jun 2013 00:21:44 -0400

Mike - 

Thanks for steadying the ship and looking for a sensible way forward.  My comments inline...

> I've just read about two weeks of WebFinger mail (catching up after vacation) have the following observations on how we might make progress towards closing the issues being discussed.

Must have been a jarring realization that vacation was over ;-)
> 1.  Explicitly state that WebFinger is a framework and that the information to be returned for specific "rel" link relation types for specific kinds of URIs is outside the scope of the specificatio…

I'm okay with this, so long as we keep clear that in addition to a framework there is a real protocol definition here that clearly prescribes on-the-wire behavior.
> 2.  We could establish a registry indexed by "rel" link relation values pointing to documents that define this information.  For instance, we could then register the "rel" value "http://openid.net/…

Sure. This is a simple step to take to provide clarity on existing uses of WF.
> 3.  Explicitly state that the link relation types that will be returned from server when no "rel" parameter is used is entirely dependent upon the services supported by that host, and that, in the…

Is this necessary? What does this buy us?
> 4.  Since people are finding the examples problematic, we could remove them, or possibly only keep the OpenID Connect one, which is concrete and being used in practice.  Or in fact, we could add a…

I've very reluctantly suggested this to Paul as well.  Not because I don't like the examples.  In fact, I consider them some of the most useful text for implementers and for their value in quickly relaying the power of current usage and future potential of the protocol.  In the interest of an expeditious resolution to this stalemate I'd be willing to remove the two examples giving problems, though I'd warn that we do have tangible useful information loss (e.g., no demonstrated use of properties, etc.).  My position on this is only because I expect to write future documents that will allow us to resurrect these deleted examples.  

BTW - The addition of a supplementary OpenID Connect example seems reasonable and helpful.
> 5.  We could remove all references to and discussion of the acct: URI, since WebFinger actually has no dependency upon it.  Other specifications can still specify that it be used in particular cont…

This is tragic considering they were so closely intertwined that they were one and the same document at one point. That said, if it helps get us to publication quickly...
> Let's focus our energies on deciding what the best next steps are to finish in a timely manner.

Amen.

Thanks,

Gonzalo

---

From: Goix Laurent Walter <[email-masked]>
Date: Wed, 19 Jun 2013 15:00:26 +0200

Hi all,

I am catching up as well a bit late and would like to move things forward for those realistic use cases. Some comments inline...

[snip]
> >
> > 1.  Explicitly state that WebFinger is a framework and that the information
> to be returned for specific "rel" link relation types for specific kinds of
> URIs is outside the scope of the specification, but is intended to be defined
> by other specifications.
>
> I'm okay with this, so long as we keep clear that in addition to a framework
> there is a real protocol definition here that clearly prescribes on-the-wire
> behavior.

[walter] +1. Actually OMA SNEW is another spec (besides OpenID Connect) that leverages webfinger for (mobile) federated social networks. I re-attach a mail I sent a couple of months ago with a related example after some discussion already on the examples section. (feedback/revision is welcome)

> >
> > 2.  We could establish a registry indexed by "rel" link relation values
> pointing to documents that define this information.  For instance, we could
> then register the "rel" value "http://openid.net/specs/connect/1.0/issuer" and
> point it to http://openid.net/specs/openid-connect-discovery-1_0.html, which
> defines the meaning of that link relation.  Other link relation definitions
> could then also use that registry.
>

[walter] link rel registry already exist at IANA and we should probably leverage on that, which is also useful for other contexts such as embedding such link rels in atom feeds or html pages for example. But surely 1) we can define new official link rel tokens that fit concrete use cases, 2) we may have an informal registry for the link rel URIs (and could use the one from Paul on packetizer as basis)

[snip]

> >
> > 4.  Since people are finding the examples problematic, we could remove them,
> or possibly only keep the OpenID Connect one, which is concrete and being used
> in practice.  Or in fact, we could add a second OpenID Connect example - so
> that there's one with the resource being a URL and another with the resource
> using e-mail address syntax.  We could also bring over the apparently-
> innocuous "copyright" and "author" examples from RFC 6415, if those would
> cause people less consternation.  But the device and e-mail examples seem to
> be generating more heat than light.
>
> I've very reluctantly suggested this to Paul as well.  Not because I don't
> like the examples.  In fact, I consider them some of the most useful text for
> implementers and for their value in quickly relaying the power of current
> usage and future potential of the protocol.  In the interest of an expeditious
> resolution to this stalemate I'd be willing to remove the two examples giving
> problems, though I'd warn that we do have tangible useful information loss
> (e.g., no demonstrated use of properties, etc.).  My position on this is only
> because I expect to write future documents that will allow us to resurrect
> these deleted examples.
>

[walter] i would really avoid removing the whole example section. This is very much helpful for developers to understand the protocol, and the document format (we re-defined JRD in this doc so it makes a lot of sense to show examples of this *new* data model). Besides openid connect I am proposing the oma snew case, but one or more fictitious examples that possibly don't harm any community (no email config, no aggrsrv, etc) and that moreover could better showcase the expressiveness of JRD would be useful IMHO.

> >
> > 5.  We could remove all references to and discussion of the acct: URI, since
> WebFinger actually has no dependency upon it.  Other specifications can still
> specify that it be used in particular contexts with WebFinger, as OpenID
> Connect does.
>
> This is tragic considering they were so closely intertwined that they were one
> and the same document at one point. That said, if it helps get us to
> publication quickly...
> >
> > I realize that the examples provide more context for developers but if
> they're standing between us and finishing the spec it would be better for them
> to go.  Likewise, if acct: is standing between us and finishing, it should go
> too.

[walter] webfinger was originally very much motivated by "account identifiers" (then became acct: URI) and as such would deserve a mention as it currently states. I don't believe that its mention limits the proposal (it clearly states that any other URI scheme is valid) but clarifies the original intent. I do not see why it would help removing it, but if it makes it ship faster...

walter

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.

Subject: [webfinger] R: Pete Resnick's Discuss on draft-ietf-appsawg-webfinger-12: (with DISCUSS and COMMENT)
From: Goix Laurent Walter <[email-masked]>
To: "Paul E. Jones" <[email-masked]>, 'Pete Resnick' <[email-masked]>, 'The IESG' <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 11 Apr 2013 10:30:35 +0200
List-Id: Discussion of the Webfinger protocol proposal in the Applications Area <webfinger.ietf.org>

Dear all,

After reading this thread and the various ballots, I'd like to help the DISCUSSion and hopefully clarify (part of) the doubts by proposing an example of usage of webfinger within federated social networks. This example is derived from the OMA Social Network Web specification, which references Webfinger for this specific purpose.
I'd also like to recall (as Paul anticipated talking about rfc6415) that social network federation was actually the first use case of the original webfinger community spec, and as such imo well deserves an example using this new spec as it may become extremely relevant in the next years.

Of course improvements are welcome if the generic idea is sound.

Walter

---
3.x Federated Social Networks
In the context of interoperable, federated, social networks, the Webfinger discovery process is used by a SN Server when receiving a request from an SN Client on behalf of a user asking to interact with a user identified by his SN account eg acct:[email-masked]. In particular the SN Server identifies whether it is authoritative for the recipient (i.e. the domain of his/her account is "locally" managed by this SN Server) or whether it pertains to another remote SN domain/provider. If the recipient's address corresponds to a "acct:" address, which domain-part corresponds to a remote domain, the SN Server can locate the recipient's SN Server based on this domain-part and trigger the Webfinger discovery process for that recipient (the "resource").
This process can hence be triggered when receiving requests to follow remote users or when receiving reactions (e.g. comments, replies, mentions) that relate to social activities of remote users, etc. Depending on the incoming request from the client, the SN Server may be interested in some specific link rels that will be used to contact the remote SN Server on the related endpoint(s). SN Servers can cache the information provided in the retrieved descriptor and/or issue conditional requests at a later stage to check for updates of this information, subject to the mechanisms defined in [RFC 2616] section 13.

The following JRD is an example of a user descriptor returned by an SN Server for a Webfinger query to user account acct:[email-masked]. In this request no specific rel is mentioned as it may be useful for the requesting SN Server to cache to entire descriptor for future needs.

{
       "subject" : "acct:[email-masked]",
       "properties" :
       {
           "http://salmon-protocol.org/ns/magic-key" : "RSA.mVgY8RN6URBTstndvmUUPb4UZTdwvwmddSKE5z_jvKUEK6yk1u3rrC9yN8k6FilGj9K0eeUPe2hf4Pj-5CmHww.AQAB"
       },
       "links" :
       [
         {
           "rel" : "http://portablecontacts.net/spec/1.0",
           "href" : "http://example.com/api/people"
         },
         {
           "rel" : "http://portablecontacts.net/spec/1.0#me",
           "href" : "http://example.com/api/people/joe"
         },
         {
           "rel" : "http://ns.opensocial.org/2008/opensocial/people",
           "href" : "http://example.com/api/people"
         },
         {
           "rel" : "http://webfinger.net/rel/profile-page",
           "type" : "text/html",
           "href" : "http://example.com/profiles/joe"
         },
         {
           "rel" : "describedby",
           "type" : "text/html",
           "href" : "http://example.com/profiles/joe"
         },
         {
           "rel" : "http://webfinger.net/rel/avatar",
           "href" : "http://example.com/profiles/joe/photo"
         },
         {
           "rel" : "http://schemas.google.com/g/2010#updates-from",
           "type" : "application/atom+xml",
           "href" : "http://example.com/activities/joe"
         },
         {
           "rel" : "salmon",
           "href" : "http://example.com/salmon/joe"
         }
       ]
}

Depending on the original request from the client the SN Server will typically read a specific link rel and invoke the related endpoint. For example it can read the http://schemas.google.com/g/2010#updates-from relation link of type "application/atom+xml" to access the user's activity stream feed or the http://portablecontacts.net/spec/1.0 relation link to access personal user information such as his profile or relationships. The actual access to such endpoints and the retrieved data ,if any, will be subject to the remote SN policies and user settings.

> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]] Per conto
> di Paul E. Jones
> Inviato: giovedì 11 aprile 2013 5.40
> A: 'Pete Resnick'; 'The IESG'
> Cc: [email-masked]; [email-masked]; draft-ietf-appsawg-
> [email-masked]
> Oggetto: Re: [webfinger] Pete Resnick's Discuss on draft-ietf-appsawg-
> webfinger-12: (with DISCUSS and COMMENT)
>
> Pete,
>
> > [All: As I noted earlier to the Webfinger mailing list, I have Cc'ed
> > this
> > to the Webfinger list along with the document authors, the document
> > shepherd, and the rest of the IESG.
> >
> > Also note that I intend to DISCUSS this until Thursday. If I get no
> > further support from the IESG and/or the WG that this is a serious and
> > showstopper problem, I will simply ABSTAIN on both this and on the
> > -acct-uri document (on which I also currently have an open DISCUSS
> > position). But it looks like Richard and I are in some agreement on
> > this.]
> >
> If you are seeking information related to a user account, then the
> specification recommends the use of the "acct" URI.  Use of other URI types is
> not fully specified and no recommendations are given.  Syntactically, the
> server behavior will be the same for any type of URI.  The only gap is knowing
> what set of link relations type to expect for a given URI scheme.  Do you use
> "mailto" or "acct"?  We had a lot of debate over that for years and settled on
> "acct".
>
> So what should one expect if one issued a query like this?
>
> $ curl https://packetizer.com/.well-
> known/webfinger?resource=http://www.packetizer.com
>
> I would expect it to return information about that URL.  The link relation
> types returned might be "copyright" or "author" or other.  It would be types
> that are valid for a web page.
>
> Again, this was a 3 year long discussion.  You're right that it could be
> anything.  We even argued to use no URI at all and just use "user@domain".
> However, it finally decided to use "acct".  It identifies an account at a
> domain.  It does not identify an email address.  Using mailto URI didn't fit
> Twitter, for example, as there is no email.  The same can be said for other
> services, including photo sharing services, blogs, and so forth.  If you want
> to query information about my account on a social networking site, it would
> not be an email address that would be used.
>
> The "rel" parameter is just a filter to reduce the size of the JRD down to
> only the particular link relation types of interest (e.g., "vcard", "jcard",
> "blog", "profile").
>
> If you wish to query for information about a person, you query the person's
> acct URI.  The other examples, such as use of "mailto" or "device" are just
> examples of what is possible.   As an example of how I would expect to use
> "mailto", you can see this presentation:
> http://www.ietf.org/proceedings/86/slides/slides-86-aggsrv-3.pdf
>
> However, the aggsrv group could say (if they even elected to use WF) that the
> "mailto" URI shall be used to query for configuration information related to
> email.  I don't know what they will recommend.  The WF draft shows an example
> of how one could use an email URI, but it is a non-working example since none
> of the link relation types are defined.
>
> The WF spec does not go into detail on what a client should expect to receive
> for any URI scheme, but only recommends use of "acct" to get user account
> information.  The link relations returned from such a query are in use today
> and some will be standardized (as that's next on the "to-do" list).
>
> Well, "device" does not exist and that will likely never exist.  The only
> point with that was to demonstrate how any URI scheme could be used, including
> one intended for device identification.  And if we had one for device
> identification, it might return that kind of information.  Again, this is just
> a non-normative example showing broadly what we can do with WF.
>
> Yeah, this definitely was not intended to be defined.  When or if we decided
> to use WF for this purpose, it would be defined in another spec.  However, I
> would expect the syntax and procedures for making the request to the server to
> be the same as querying for an account URI.
>
> URI schemes allow for a natural separation.  And, a WF server for a domain
> could know all kinds of information about itself.  It would know who authored
> web pages on the domain.  It would know information about account holders on
> the domain.  There was back and forth, as I noted above, as to whether we
> needed "acct" or not.  In the end, it was agreed to identify information about
> users -- stuff users share or that are shared within a company (e.g., employee
> pictures or contact info).
>
> Years of work on this topic resulted in RFC 6415.  RFC 6415, in fact, is what
> people had envisaged for "webfinger".  It defined a well-known location called
> "host-meta" and a different link relation called "LRDD" for querying
> information about a particular URI.
>
> The challenge with RFC 6415 is that it too so long to move forward that by the
> time it was done, JSON had become the favored syntax language, people wanted
> to mandate use of TLS for a variety of security reasons, people did not want
> two round trips to the server to return the JRD.  So, we set about fixing all
> of the gripes people had with RFC 6415.  We removed XML entirely, we fully
> documented JRD, the server does the merging of host-meta and LRDD documents
> (though not described that way for simplicity's sake), TLS was mandated, and
> we introduced the "rel" parameter to allow for selecting one or a few types of
> links to reduce the size of the document.
>
> RFC 6415 uses any type of URI.  This is useful, since the URI scheme does
> provide separation in namespace and since we do want to allow retrieval of a
> set of link relations for those URIs -- web pages (http), user accounts
> (acct), tel URIs (tel), etc.  The only point of confusion, I think, is "what
> do we do with mailto, sip, h323, telnet, etc.?"  Well, we're not prescribing
> that.  That would be documented in a document that wants to use those other
> URIs.  They might be used to configure a device or help route a call or
> whatever.  We only have examples of possible use, but we do not specify their
> use.
>
> Paul
>
>

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: Melvin Carvalho <[email-masked]>
Date: Wed, 19 Jun 2013 15:17:24 +0200

On 19 June 2013 15:00, Goix Laurent Walter <
[email-masked]> wrote:

> Hi all,
>
> I am catching up as well a bit late and would like to move things forward
> for those realistic use cases. Some comments inline...
>
> [snip]
> > >
> information
> [walter] +1. Actually OMA SNEW is another spec (besides OpenID Connect)
> that leverages webfinger for (mobile) federated social networks. I
> re-attach a mail I sent a couple of months ago with a related example after
> some discussion already on the examples section. (feedback/revision is
> welcome)
>
> > >
> > then register the "rel" value "
> http://openid.net/specs/connect/1.0/issuer" and
> [walter] link rel registry already exist at IANA and we should probably
> leverage on that, which is also useful for other contexts such as embedding
> such link rels in atom feeds or html pages for example. But surely 1) we
> can define new official link rel tokens that fit concrete use cases, 2) we
> may have an informal registry for the link rel URIs (and could use the one
> from Paul on packetizer as basis)
>
> [snip]
>
> > >
> > BTW - The addition of a supplementary OpenID Connect example seems
> reasonable
> > and helpful.
>
> [walter] i would really avoid removing the whole example section. This is
> very much helpful for developers to understand the protocol, and the
> document format (we re-defined JRD in this doc so it makes a lot of sense
> to show examples of this *new* data model). Besides openid connect I am
> proposing the oma snew case, but one or more fictitious examples that
> possibly don't harm any community (no email config, no aggrsrv, etc) and
> that moreover could better showcase the expressiveness of JRD would be
> useful IMHO.
>
> > >
> [walter] webfinger was originally very much motivated by "account
> identifiers" (then became acct: URI) and as such would deserve a mention as
> it currently states. I don't believe that its mention limits the proposal
> (it clearly states that any other URI scheme is valid) but clarifies the
> original intent. I do not see why it would help removing it, but if it
> makes it ship faster...
>

I think the original webfinger was motivated by email identiiers and acct:
came in later

http://code.google.com/p/webfinger/

"WebFinger is about making email addresses more valuable, by letting people
attach public metadata to them"

>
> walter
>
> 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.
>
>
>
> ---------- Forwarded message ----------
> To: "Paul E. Jones" <[email-masked]>, 'Pete Resnick' <
> [email-masked]>, 'The IESG' <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>
> Subject: [webfinger] R: Pete Resnick's Discuss on
> draft-ietf-appsawg-webfinger-12: (with DISCUSS and COMMENT)
> Dear all,
>
> After reading this thread and the various ballots, I'd like to help the
> DISCUSSion and hopefully clarify (part of) the doubts by proposing an
> example of usage of webfinger within federated social networks. This
> example is derived from the OMA Social Network Web specification, which
> references Webfinger for this specific purpose.
> I'd also like to recall (as Paul anticipated talking about rfc6415) that
> social network federation was actually the first use case of the original
> webfinger community spec, and as such imo well deserves an example using
> this new spec as it may become extremely relevant in the next years.
>
> In the context of interoperable, federated, social networks, the Webfinger
> discovery process is used by a SN Server when receiving a request from an
> SN Client on behalf of a user asking to interact with a user identified by
> his SN account eg acct:[email-masked]. In particular the SN Server
> identifies whether it is authoritative for the recipient (i.e. the domain
> of his/her account is "locally" managed by this SN Server) or whether it
> pertains to another remote SN domain/provider. If the recipient's address
> corresponds to a "acct:" address, which domain-part corresponds to a remote
> domain, the SN Server can locate the recipient's SN Server based on this
> domain-part and trigger the Webfinger discovery process for that recipient
> (the "resource").
> This process can hence be triggered when receiving requests to follow
> remote users or when receiving reactions (e.g. comments, replies, mentions)
> that relate to social activities of remote users, etc. Depending on the
> incoming request from the client, the SN Server may be interested in some
> specific link rels that will be used to contact the remote SN Server on the
> related endpoint(s). SN Servers can cache the information provided in the
> retrieved descriptor and/or issue conditional requests at a later stage to
> check for updates of this information, subject to the mechanisms defined in
> [RFC 2616] section 13.
>
> The following JRD is an example of a user descriptor returned by an SN
> Server for a Webfinger query to user account acct:[email-masked]. In
> this request no specific rel is mentioned as it may be useful for the
> requesting SN Server to cache to entire descriptor for future needs.
>
> {
>            "http://salmon-protocol.org/ns/magic-key" :
> "RSA.mVgY8RN6URBTstndvmUUPb4UZTdwvwmddSKE5z_jvKUEK6yk1u3rrC9yN8k6FilGj9K0eeUPe2hf4Pj-5CmHww.AQAB"
>        },
>        "links" :
>        [
>          {
> Depending on the original request from the client the SN Server will
> typically read a specific link rel and invoke the related endpoint. For
> example it can read the http://schemas.google.com/g/2010#updates-fromrelation link of type "application/atom+xml" to access the user's activity
> stream feed or the http://portablecontacts.net/spec/1.0 relation link to
> access personal user information such as his profile or relationships. The
> actual access to such endpoints and the retrieved data ,if any, will be
> subject to the remote SN policies and user settings.
>
> > > identifier? (See
> http://datatracker.ietf.org/doc/draft-ietf-radext-nai/
> 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: Pete Resnick <[email-masked]>
Date: Thu, 20 Jun 2013 15:41:00 -0500

Sorry for the delay. A few comments, but generally a good direction here:

> 1.  Explicitly state that WebFinger is a framework and that the information to be returned for specific "rel" link relation types for specific kinds of URIs is outside the scope of the specificatio…

Fine, of course.

> 2.  We could establish a registry indexed by "rel" link relation values pointing to documents that define this information.  For instance, we could then register the "rel" value "http://openid.net/…

This sounds reasonable, though I would add a third column (well, 
actually I would make it the first column of 3) called "Service". In 
this case, the service would be "Open ID Connect Issuer". As time goes 
on, I'd expect there to be things like "Mail Client Configuration", 
"User Account Info", and other such entries.

> 3.  Explicitly state that the link relation types that will be returned from server when no "rel" parameter is used is entirely dependent upon the services supported by that host, and that, in the…

I've always found this a weird case and never understood why you'd want 
to allow queries without "rel" parameters; I don't understand why a 
client would ever want to do that. But if you're going to do that, this 
explanation seems useful. As I've said a few times now, what this 
document is missing is some hint of how the client is going to figure 
out what it needs to do.

> 4.  Since people are finding the examples problematic, we could remove them, or possibly only keep the OpenID Connect one, which is concrete and being used in practice.  Or in fact, we could add a…

Agreed. One other possibility is simply to remove all examples, but have 
an informative reference to an existing spec, e.g. OpenID Connect.

> 5.  We could remove all references to and discussion of the acct: URI, since WebFinger actually has no dependency upon it.  Other specifications can still specify that it be used in particular cont…

I'd like to see how the acct: URI discussion shakes out before making 
that call. For a while, the two document seemed inextricably linked. 
Now, I'm not sure.

This is a reasonable start toward addressing my concerns. I look forward 
to some proposed text.

pr

---

From: Goix Laurent Walter <[email-masked]>
Date: Fri, 21 Jun 2013 09:34:18 +0200

> > 3.  Explicitly state that the link relation types that will be returned from
> server when no "rel" parameter is used is entirely dependent upon the services
> supported by that host, and that, in the general case, clients must be
> prepared for the response to be the empty set for any particular resource.
> >
>

[walter] is there then interest for creating a new concept of "rel sets" (similarly to what you called "Service") that could have a unique name/URI (in case of simple token a registry may be useful) and would be documented in an external spec as a specific list of rels? This may help in querying on wf with a single param (avoiding to list explicitly all rels) and at the same time facilitate interop so that the client could explicitly state what it is looking for.
"openidconnect" could be one of them (no matter how many rels it covers, which would be listed in the openidconnect spec), , the "oauth" related rels could be another, and others may be created eg for federated social web (thinking of salmon, pubsub, etc) link rels...

Would this make the spec too complex if we define such additional (optional) parameter and manage the naming conventions just like for rels ?

walter

---

From: 'Stephane Bortzmeyer' <[email-masked]>
Date: Fri, 28 Jun 2013 12:10:33 +0200

On Fri, Jun 14, 2013 at 12:28:10PM -0400,
 Paul E. Jones <[email-masked]> wrote 

> What's the issue with "en-us"?

http://www.ietf.org/mail-archive/web/webfinger/current/msg00555.html

RFC 5646 says:

>      Use as precise a tag as possible, but no more specific than is
>      justified.  Avoid using subtags that are not important for
>      distinguishing content in an application.
>
>       * For example, 'de' might suffice for tagging an email written
>          in German, while "de-CH-1996" is probably unnecessarily
>          precise for such a task.

Which seems to apply exactly here (there is nothing US-specific in the
sentence). May be, instead:

"titles" :
           {
               "en-us" : "The Magical Theater of Bob",
               "en-gb" : "The Magical Theatre of Bob",
...

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 28 Jun 2013 06:47:02 -0400

Stephane,

If I am entering the text that goes into the WF output and I spell words
using US English, then en-us is the appropriate thing to put.  Just because
the spelling in that particular example aligns with British spelling does
not mean there is no significance.

Following your example, I assume you would agree with this:

    {
        "en-us" : "The Magical Theater of Bob",
        "fr" : "Le Théâtre magique de Bob"
    }

But the software didn't change.  And my WF server is not going to have a
language analyzer to know the least restrictive value to use.  The language
tag is likely going to be fairly automatic and derived from the user's
locale.

Paul

> From: 'Stephane Bortzmeyer' [mailto:[email-masked]]
> Sent: Friday, June 28, 2013 6:11 AM
> To: Paul E. Jones
> Cc: [email-masked]