Subject: [apps-discuss] Webfinger: acct "link relation"

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 14 Mar 2012 01:56:44 -0400

Folks,

In the latest Webfinger draft, we introduced a "acct" link relation named
"acct" (see Section 6).  The intent with that link relation was to allow for
one to inform a webfinger client that a user's account information may be
retrieved elsewhere.  I believe this will be important, since a user might
have more than one account and this might serve as a means of associating
them.  Certainly, it would be a way of retrieving information from those
other accounts automatically.

Perhaps calling the new link relation "acct" is too restrictive, though.  If
one used Webfinger to query other kinds of information other than a user's
account, there may still be a need/desire to refer the Webfinger client to
other resources.

What do you think about changing this section such that the link relation is
renamed to "seealso"?  This would still be useful when querying an acct URI,
but would also be useful when querying any URI since it  is more generic.

Do note that "seealso" would be different than the "alternate" link
relation.  It would not refer to alternative information, but would refer to
supplemental information.  In practice, the supplemental information may be
the more informative since the bulk of the information related to a user
might be held under a different account.

Your thoughts?

Paul

---

From: Goix Laurent Walter <[email-masked]>
Date: Wed, 14 Mar 2012 12:19:11 +0100

Well, generalizing could be a more flexible approach. Especially if uri schemes evolve over time to identify users (could be http, tel, etc). I guess the semantics here is o refer to yet another identity of that individual.

"seealso" may fit, although it is quite vague semantically and do not specifically ensure that the specific resource is actually the same individual but another account.

The "related" relation link (defined in atom [1] ) may also fit and has more or less the same meaning whilst being already formally assigned.
In alternative one could borrow from xfn concepts [2] and use "me" to clearly state that this resource is another pointer to "myself"...

Just my 2 cents to stimulate the discussion here
walter

[1] http://tools.ietf.org/html/rfc4287#section-4.2.7.2
[2] http://gmpg.org/xfn/11
Da: [email-masked] [mailto:[email-masked]] Per conto di Paul E. Jones
Inviato: mercoledì 14 marzo 2012 6.57
A: [email-masked]; [email-masked]
Oggetto: [apps-discuss] Webfinger: acct "link relation"

Folks,

In the latest Webfinger draft, we introduced a "acct" link relation named "acct" (see Section 6).  The intent with that link relation was to allow for one to inform a webfinger client that a user's account information may be retrieved elsewhere.  I believe this will be important, since a user might have more than one account and this might serve as a means of associating them.  Certainly, it would be a way of retrieving information from those other accounts automatically.

Perhaps calling the new link relation "acct" is too restrictive, though.  If one used Webfinger to query other kinds of information other than a user's account, there may still be a need/desire to refer the Webfinger client to other resources.

What do you think about changing this section such that the link relation is renamed to "seealso"?  This would still be useful when querying an acct URI, but would also be useful when querying any URI since it  is more generic.

Do note that "seealso" would be different than the "alternate" link relation.  It would not refer to alternative information, but would refer to supplemental information.  In practice, the supplemental information may be the more informative since the bulk of the information related to a user might be held under a different account.

Your thoughts?

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.

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

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 14 Mar 2012 11:08:03 +0100

On 14 March 2012 06:56, Paul E. Jones <[email-masked]> wrote:

> Folks,****
>
> ** **
>
> In the latest Webfinger draft, we introduced a “acct” link relation named
> “acct” (see Section 6).  The intent with that link relation was to allow
> for one to inform a webfinger client that a user’s account information may
> be retrieved elsewhere.  I believe this will be important, since a user
> might have more than one account and this might serve as a means of
> associating them.  Certainly, it would be a way of retrieving information
> from those other accounts automatically.****
>
> ** **
>
> Perhaps calling the new link relation “acct” is too restrictive, though.
> If one used Webfinger to query other kinds of information other than a
> user’s account, there may still be a need/desire to refer the Webfinger
> client to other resources.****
>
> ** **
>
> What do you think about changing this section such that the link relation
> is renamed to “seealso”?  This would still be useful when querying an acct
> URI, but would also be useful when querying any URI since it  is more
> generic.****
>
> ** **
>
> Do note that “seealso” would be different than the “alternate” link
> relation.  It would not refer to alternative information, but would refer
> to supplemental information.  In practice, the supplemental information may
> be the more informative since the bulk of the information related to a user

seeAlso already exists as an "extended relation type"

http://www.w3.org/TR/2000/CR-rdf-schema-20000327/#s2.3.4

Seems like a good choice.  In fact, timbl uses it in his profile:

$ rapper -g http://www.w3.org/People/Berners-Lee/card | grep seeAlso

<http://www.w3.org/People/Berners-Lee/card#i>
    <http://www.w3.org/2000/01/rdf-schema#seeAlso> <
http://dig.csail.mit.edu/2008/webdav/timbl/foaf.rdf> .

sameas is also similar

<http://www.w3.org/People/Berners-Lee/card#i>
    <http://www.w3.org/2002/07/owl#sameAs> <http://identi.ca/user/45563> .

> ****
> ** **
> Your thoughts?****
> ** **
> Paul****
> ** **
> ** **
> ** **

---

From: Michiel de Jong <[email-masked]>
Date: Wed, 14 Mar 2012 06:56:33 +0000

one very nice application of that would be to facilitate implementation of
user-editable webfinger. There will be resources that an identity provider
wants to announce by default for all their users, but maybe some (power)
users want to announce some additional machine-readable pointers related to
their user address. Separating user-provided links from provider-provided
:) might make a lot of sense where you don't want the provider-provided
stuff to break. In case of conflict i think the 'seealso' one should always
lose. That way, you can give your users the freedom to paste whatever links
they want into their profile settings, without fear of that breaking your
service's well-tested federation features.

user-editable webfinger would be an amazing feature, and whereas in theory
you could offer it already, allowing users to paste stuff into the bowels
of your service's federation mechanism feels just wrong, adding a seealso
link to a section on the user's profile page, where the user already has
things like a bio, interests, location, etcetera, feels a lot more right. i
guess it's a software architecture consideration.

On Wed, Mar 14, 2012 at 5:56 AM, Paul E. Jones <[email-masked]>wrote:

> might be held under a different account.****
>
> ** **
>
> Your thoughts?****
>
> ** **
>
> Paul****
>
> ** **
>
> ** **
>
> ** **
>

---

From: Bob Wyman <[email-masked]>
Date: Wed, 14 Mar 2012 11:25:48 -0400

Thanks for mentioning section 6. I have been puzzling over this for some
time now. It seems to me that if Alice receives an email from "
[email-masked]" then, because there is no certain equivalence of
mailto:and acct: identifiers, Alice should query for "mailto:
[email-masked]" in order to discover "acct:[email-masked]" rather than
assuming similarity between the mailto: and acct: identifiers and first
querying for "acct:[email-masked]."
It must be remembered that WebFinger acct: identifiers need not be the same
as or even similar to mailto: identifiers. Additionly, similar identifiers,
such as "mailto:[email-masked]" and "acct:[email-masked]," need not
identify the same person or entity. (although it would be really, really
smart if they did...)

Given that in most cases, "acct:xxx" and "mailto:xxx" will, in fact, be
associated with the same entity, it would be a bit of a nuisance to require
the multi-step discovery process outlined above. Especially since we know
that mapping from mailto: to acct: will be a very, very common requirement.
Thus, it seems reasonable to me that we would add a few new rules:
1) If the server responding to a request for mailto: information is also
the authoritative server for the WebFinger acct information, it may provide
that information as long as it also provides a link with rel=acct element
to identify the acct:. In this case, it should be understood that any
information provided (other than the link that shows the relationship
between the identifiers) is associated with the acct: identifier, not with
the mailto: identifier. This server-side automatic mapping rule could, of
course, be generalized to say that whenever the server knows the exact
mapping from any URI, no matter what scheme it uses, to a corresponding
acct: URI, it may perform the translation as long as it provides an
appropriate link with (rel=acct) in its response.
2) To enable clients to do URI translations, it would be useful for servers
to be able to describe those translations which are easily performed. For
instance, for servers that maintain a one-to-one relationship between
mailto: and acct: URIs, it should be possible for the server to publish in
its host metadata the mapping between the two identifiers. Thus, we might
have an XRD like the following:

    <XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0">
       <Link rel="lrdd"
             type="application/xrd+xml"
             template="https://example.com/lrdd/?uri={uri}"/>
*<Link rel="mailto2acct" template="acct:{mailto_id}"/>*
     </XRD>

The XRD above not only describes the general template for forming queries,
it gives specific instructions re optional pre-translation for
mailto:URIs. Clearly, more complex template mappings would be
interesting and
often useful, but perhaps too complex.

bob wyman

> “acct” (see Section 6).  The intent with that link relation was to allow
for
> one to inform a webfinger client that a user’s account information may be
If
> one used Webfinger to query other kinds of information other than a user’s
is
> renamed to “seealso”?  This would still be useful when querying an acct
URI,
> relation.  It would not refer to alternative information, but would refer
to
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 14 Mar 2012 11:54:09 -0400

Michael,

I would hope that virtually every piece of information stored in a user's
profile is editable, though I can imagine some information may not be.  In
any case, that largely seems to be an account management user interface
issue.  Are you suggesting a change in the Webfinger protocol?

Paul

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Michiel de Jong
Sent: Wednesday, March 14, 2012 2:57 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Webfinger: acct "link relation"

one very nice application of that would be to facilitate implementation of
user-editable webfinger. There will be resources that an identity provider
wants to announce by default for all their users, but maybe some (power)
users want to announce some additional machine-readable pointers related to
their user address. Separating user-provided links from provider-provided :)
might make a lot of sense where you don't want the provider-provided stuff
to break. In case of conflict i think the 'seealso' one should always lose.
That way, you can give your users the freedom to paste whatever links they
want into their profile settings, without fear of that breaking your
service's well-tested federation features.

user-editable webfinger would be an amazing feature, and whereas in theory
you could offer it already, allowing users to paste stuff into the bowels of
your service's federation mechanism feels just wrong, adding a seealso link
to a section on the user's profile page, where the user already has things
like a bio, interests, location, etcetera, feels a lot more right. i guess
it's a software architecture consideration.

On Wed, Mar 14, 2012 at 5:56 AM, Paul E. Jones <[email-masked]>
wrote:

Folks,

Your thoughts?

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 14 Mar 2012 11:59:22 -0400

Melvin,

I, too, like the idea of introducing "seealo" that would have wider
applicability.  For example, consider this page:

http://www.techabulary.com/h/h323/

The bottom of this page refers the reader to several other resources for
additional information.  I think having "seealso" generally available as a
web link relation would allow a web site to suggest related reading material
and the browser could offer up that list via a consistent user interface for
the user.

Now, should we document "seealso" in the Webfinger draft or should that be
in its own draft?

Paul

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Melvin Carvalho
Sent: Wednesday, March 14, 2012 6:08 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Webfinger: acct "link relation"

Folks,

<http://www.w3.org/People/Berners-Lee/card#i> 
    <http://www.w3.org/2000/01/rdf-schema#seeAlso>
<http://dig.csail.mit.edu/2008/webdav/timbl/foaf.rdf> .
 
sameas is also similar

 

Your thoughts?

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 14 Mar 2012 12:04:05 -0400

Kingsley,

Oh, I was not aware of the "related" scheme.  So, if "related" and "seealso"
have the same semantics, then I would not want to introduce a new one.

Are there different semantics?

Would we prefer to  use "seealso" or "related" or "acct" to refer webfinger
to go look at a different account URI?

Paul

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kingsley Idehen
Sent: Wednesday, March 14, 2012 10:38 AM
To: [email-masked]
Subject: Re: Webfinger: acct "link relation"

On 3/14/12 1:56 AM, Paul E. Jones wrote: 

Folks,

Your thoughts?

Paul

+1 for "seeAlso" . But, this is analogous to "related" which already exists
i.e., <link rel="related" .../> :-)

-- 
 
Regards,
 
Kingsley Idehen             
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 14 Mar 2012 15:38:18 -0400

Bob,

I want to improve the language in the introduction of that section, but I do
think it is reasonable to assume that a user with a given email address may
have an account with the same name on the server.  There are instances where
that would not be the case, but a 404 would be returned in that instance.
It has been suggested that perhaps making this assumption would lead to
returning information for the wrong person.  That's possible, but I believe
Webfinger might help to encourage domain owners from putting themselves in
that situation.  If [email-masked] is a non-email account at that domain,
there should not be a real user account with the same name, but belonging to
a different person.  It's simply poor practice.  It confuses humans.  We
could get this straight in protocol, but it would never address the
confusion in the human mind.

In any case, I want the "acct" link relation to refer to other accounts, not
necessarily the "right" account.  The wording was not clear on that.  Here's
the proposed wording changes for the first 3 paragraphs (now reduced to
two):

Users of some services might have an acct URI that looks significantly
different from their email address, perhaps using entirely different domain
names.  It is also possible that a user has multiple accounts that a
Webfinger client may want to query.  As such, it is useful to allow one user
account to refer to one or more other account identifiers.

To make a reference to other user accounts, one uses the "acct" link
relation.  Consider the following example.

I welcome any textual changes to make this clearer.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Wyman
Sent: Wednesday, March 14, 2012 11:26 AM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: Re: [apps-discuss] Webfinger: acct "link relation"

Thanks for mentioning section 6. I have been puzzling over this for some
time now. It seems to me that if Alice receives an email from
"[email-masked]" then, because there is no certain equivalence of mailto:
and acct: identifiers, Alice should query for "mailto:[email-masked]" in
order to discover "acct:[email-masked] <mailto:[email-masked]> "
rather than assuming similarity between the mailto: and acct: identifiers
and first querying for "acct:[email-masked] <mailto:[email-masked]>
." 
It must be remembered that WebFinger acct: identifiers need not be the same
as or even similar to mailto: identifiers. Additionly, similar identifiers,
such as "mailto:[email-masked]" and "acct:[email-masked]
<mailto:[email-masked]> ," need not identify the same person or
entity. (although it would be really, really smart if they did...)

1) If the server responding to a request for mailto: information is also the
authoritative server for the WebFinger acct information, it may provide that
information as long as it also provides a link with rel=acct element to
identify the acct:. In this case, it should be understood that any

    <XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0">
       <Link rel="lrdd"
             type="application/xrd+xml"
             template="https://example.com/lrdd/?uri={uri}
<https://example.com/lrdd/?uri=%7buri%7d> "/>
       <Link rel="mailto2acct" template="acct:{mailto_id}"/>

     </XRD>

The XRD above not only describes the general template for forming queries,
it gives specific instructions re optional pre-translation for mailto: URIs.
Clearly, more complex template mappings would be interesting and often
useful, but perhaps too complex.

bob wyman

is
to

---

From: Bob Wyman <[email-masked]>
Date: Wed, 14 Mar 2012 16:00:42 -0400

Paul,
If one may assume that mailto:[email-masked] and
acct:[email-masked] associated with the same user, shouldn't it
be stated in the RFC that
clients MAY assume this and that servers MUST NOT allow for the assumption
to be invalid? Certainly, allowing the two identifiers to be associated
with different people will cause never-ending confusion, however, if we
want to prevent the confusion, then we should explicitly state that this
situation should not arise.

Note: I support your efforts to clarify the situation where a
mailto:corresponds to a dissimilar acct:. Also, allowing user editing
of WebFinger
data, will drastically increase the utility of the protocol.

bob wyman

On Wed, Mar 14, 2012 at 3:38 PM, Paul E. Jones <[email-masked]>wrote:

> Bob,****
>
> ** **
>
> I want to improve the language in the introduction of that section, but I
> do think it is reasonable to assume that a user with a given email address
> *may* have an account with the same name on the server.  There are
> instances where that would not be the case, but a 404 would be returned in
> that instance.  It has been suggested that perhaps making this assumption
> would lead to returning information for the wrong person.  That’s possible,
> but I believe Webfinger might help to encourage domain owners from putting
> themselves in that situation.  If [email-masked] is a non-email account
> at that domain, there should not be a real user account with the same name,
> but belonging to a different person.  It’s simply poor practice.  It
> confuses humans.  We could get this straight in protocol, but it would
> never address the confusion in the human mind.****
>
> ** **
>
> In any case, I want the “acct” link relation to refer to other accounts,
> not necessarily the “right” account.  The wording was not clear on that.
> Here’s the proposed wording changes for the first 3 paragraphs (now reduced
> to two):****
>
> ** **
>
> Webfinger client may want to query.  As such, it is useful to allow one
> user account to refer to one or more other account identifiers.****
>
> ** **
>
> To make a reference to other user accounts, one uses the “acct” link
> relation.  Consider the following example.****
>
> ** **
>
> I welcome any textual changes to make this clearer.****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Bob
> Wyman
> *Sent:* Wednesday, March 14, 2012 11:26 AM
> *To:* Paul E. Jones
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [apps-discuss] Webfinger: acct "link relation"****
>
> ** **
>
> [email-masked]" then, because there is no certain equivalence of mailto:and acct: identifiers, Alice should query for "mailto:
> It must be remembered that WebFinger acct: identifiers need not be the
> same as or even similar to mailto: identifiers. Additionly, similar
> identifiers, such as "mailto:[email-masked]" and "acct:[email-masked],"
> need not identify the same person or entity. (although it would be really,
> really smart if they did...)
>
> that mapping from mailto: to acct: will be a very, very common
> requirement. Thus, it seems reasonable to me that we would add a few new
> rules:
> 2) To enable clients to do URI translations, it would be useful for
> servers to be able to describe those translations which are easily
> performed. For instance, for servers that maintain a one-to-one
> relationship between mailto: and acct: URIs, it should be possible for
> the server to publish in its host metadata the mapping between the two
> identifiers. Thus, we might have an XRD like the following:****
>
>     <XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0">****
>
>        <Link rel="lrdd"****
>
>              type="application/xrd+xml"****
>
>              template="https://example.com/lrdd/?uri={uri}"/>****
>
>      </XRD>****
> it gives specific instructions re optional pre-translation for mailto:URIs. Clearly, more complex template mappings would be interesting and
> > Perhaps calling the new link relation “acct” is too restrictive,
> though.  If

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 14 Mar 2012 21:49:12 -0400

Bob,

I used an example wherein the client makes an assumption.  However, I feel a
little nervous about putting in normative statements that declare that this
is the way it must work.  My email client also makes the assumption when I
type an address that looks like an email address that it is one.  Such
client-side "intelligent" assumptions are reasonable to make life easier for
users, but I think it is best to leave that as non-normative.

What I want to do is split section 6 into 6.1 and 6.2.  In 6.1, I'll
introduce the purpose for the "acct" URI, void of any example usage.  In
6.2, I'll have a non-normative example (one like what is there presently.)

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Wyman
Sent: Wednesday, March 14, 2012 4:01 PM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: Re: [apps-discuss] Webfinger: acct "link relation"

Paul,

If one may assume that mailto:[email-masked] and acct:[email-masked]
<mailto:[email-masked]>  are associated with the same user,
shouldn't it be stated in the RFC that clients MAY assume this and that
servers MUST NOT allow for the assumption to be invalid? Certainly, allowing
the two identifiers to be associated with different people will cause
never-ending confusion, however, if we want to prevent the confusion, then
we should explicitly state that this situation should not arise.

Note: I support your efforts to clarify the situation where a mailto:
corresponds to a dissimilar acct:. Also, allowing user editing of WebFinger
data, will drastically increase the utility of the protocol.

bob wyman

On Wed, Mar 14, 2012 at 3:38 PM, Paul E. Jones <[email-masked]>
wrote:

Bob,

Paul

 
     </XRD>

bob wyman

is
to

---

From: Michiel de Jong <[email-masked]>
Date: Wed, 14 Mar 2012 19:13:20 +0000

Now that i think some more about it, you're right, it's unrelated.

But I do think there is a psychological problem, in that people don't use
the template='...{uri}...' syntax to its full potential. what you see
happening a lot is something like:

http://www.mysite.com/webfinger?q={uri}

On the statics server probably, in an MVC controller that has no access to
the user profile database, probably. In the 'federation stuff' part of the
site, and not in the 'human-viewable' part of the website. That's the wrong
approach to the software architecture of a webfinger-capable website, i
just realised. If you are already publishing human-readable "public
profile" page on, say,

https://profiles.mysite.com/username

then you should use a lrdd template something a lot more like:

https://profile.mysite.com/{uri}?format=jrd

that way one controller can fetch a user's bio, interests, full name, and
birthday and your MVC can spit out that same information in either html or
xrd or jrd, depending on who is asking (a human or a machine).

but you're right, it was purely a problem in software architecture, and the
correct solution for it is to use on the one hand your MVC framework, and
on the other the already existing indirection in the host-meta's lrdd
template, to make them both do what they were designed for.

Cheers!
Michiel

On Wed, Mar 14, 2012 at 3:54 PM, Paul E. Jones <[email-masked]>wrote:

> Michael,****
>
> ** **
>
> I would hope that virtually every piece of information stored in a user’s
> issue.  Are you suggesting a change in the Webfinger protocol?****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Michiel de Jong
> *Sent:* Wednesday, March 14, 2012 2:57 AM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: Webfinger: acct "link relation"****
>
> ** **
>
> wrote:****