Webfinger: acct "link relation"
Paul E. Jones
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
Michiel de Jong
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.
Melvin Carvalho
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
Kingsley Idehen
-- 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
Bob Wyman
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:b...@example.net" and "acct:b...@example.net," 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>
bob wyman
> apps-discuss mailing list
> apps-d...@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
Paul E. Jones
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
Paul E. Jones
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: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On Behalf Of Melvin Carvalho
Sent: Wednesday, March 14, 2012 6:08 AM
To: webf...@googlegroups.com
Cc: apps-d...@ietf.org
Subject: Re: Webfinger: acct "link relation"
On 14 March 2012 06:56, Paul E. Jones <pau...@packetizer.com> wrote:
Paul E. Jones
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: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On Behalf Of Kingsley Idehen
Sent: Wednesday, March 14, 2012 10:38 AM
To: webf...@googlegroups.com
Subject: Re: Webfinger: acct "link relation"
On 3/14/12 1:56 AM, Paul E. Jones wrote:
Kingsley Idehen
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?
For more specific relations you have:
1. acc
2. hasAccount
3. foaf:account -- which has the benefit of machine discernible semantics (see: http://xmlns.com/foaf/spec/#term_account ).
Kingsley
Michiel de Jong
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
Paul E. Jones
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 us...@example.com 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
Bob Wyman
Paul E. Jones
OK, I think it’s best to keep the “acct” link relation as (I hope) it is more concrete. It means that the user has another account and information is available there, whereas “related” might make a referece to a friend’s account or some such.
I’ll leave the draft as it is.
Daniel E. Renfer
must the href contain a valid acct: uri?
One of the problems I've had is discovering what the username and domain of user should be when I only have a profile url to work off of. (eg. salmon mentions) My current solution has been to parse the page, find the atom link, parse the atom document, and extract the preferredUsername. I know this is out of scope for this group.
Would it make sense to put a link with rel="acct" in my user profile pages?
Paul E. Jones
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 E. Jones
Daniel,
It is not an Alias. Per the XRD spec, an Alias “does not identify additional resources the XRD is describing, but rather provides additional identifiers for the same resource”. What the acct Link Relation does is just the opposite: it provides a URI for a different resource. It just happens to be another account owned by the same user.
The href for the “acct” link relation must be a valid acct URI, yes.
You absolutely could put a rel=”acct” in the web page. That might be considered redundant, but I can see a use for it. For example, if I have a blog on some site somewhere, the service provider offering that blog service might not offer a webfinger service for me. By inserting a <Link> header in the HTML document itself, I can refer people to where my account information is stored.
Paul
Laurent-Walter Goix
i initially answered on the ietf apps-discuss list but it seems it
didn't get here. and i could see some emails here that did not appear
there. so i guess in general it would be good to use only a single
mailing-list for these discussions also in the future (i would suggest
ietf but i leave to the authors to decide)
that said the "seealso"/"related" (more standard) look like they are
not clear enough in stating that the uri relates to the same person.
"foaf.account" or even "me" (from xfn) as rel type may enforce this
better.
regarding the discussion on acct vs mailto i would avoid any specific
statement on the fact that they may or may not be the same for the
same person. i would also like to point you to a similar example with
SIP URI, which also follow the user@domain pattern and had similar
discussion 10 years ago. i guess it could be a good starting point,
see http://tools.ietf.org/html/rfc3261#page-148
we may also clarify the scope of webfinger wrt the "acct" scheme: at
this stage both are quite tight to each other at least conceptually as
we are talking about "social network" accounts typically, and the
discovery of the related information. it seems that some people are
envisioning this protocol to discover information related to any type
of url (mailto, http, could be sip, etc). this is clearly a much wider
scope that may impact the spec a lot, so probably it would be good to
clarify this first.
walter
> Google+ Profile:https://plus.google.com/112399767740508618350/about
> LinkedIn Profile:http://www.linkedin.com/in/kidehen
>
> --
>
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Company Web:http://www.openlinksw.com
> Personal Weblog:http://www.openlinksw.com/blog/~kidehen