'301 like' redirect? for moving to another webfinger

[elf Pavlik]

Hello,

In situations when one wants to switch to another webfinger, like for example leaving gmail.com and going to something more personal like franky.me. How to state in the old XRD that now I use a different webfinger so everyone having any kind of subscription to old one can automatically update?

Something in lines of HTTP 301 redirect...

Thanks!
=)
~ elf Pavlik ~
--
(living strictly moneyless already for over 2 years)
http://wwelves.org/perpetual-tripper
http://moneyless.info
http://hackers4peace.net

[Michiel de Jong]

i think a http redirect would be correct way to delegate authority, and should be supported by clients as part of 'fetching the file using http(s)'. a bigger problem will be how to convince the gmail sysadmins to put the redirect there for you. even though your lrdd file is your profile, and you as a user (not the domain admins) should own it, few domain admins seem to be giving tools to their users for this. as part of 'identity liberation', each webfinger provider should IMO offer an option somewhere in the website options menu saying 'provide alternative lrdd url'.

another question is how to tell your friends to stop addressing you at your gmail address, and to start using your franky.me address as your "name". one thing to link the two would i guess be adding a link with rel="me" and href="acct:y...@franky.me" maybe? but then still you haven't stated which one is your main/preferred/principal address. maybe someone else has a better answer to that.


my 2ct,
Michiel.

[John Panzer]

rel="canonical"?

--
John Panzer / Google

[Paul E. Jones]

If a user, say b...@example.com, should have Webfinger replies from somewhere other than example.com, then do note that at least some information in host-meta will still be returned to the requesting client. The LRDD response could be a redirection -- and that's probably reasonable.

I have another requirement: I'd like to be able to define a link relation that says, "in addition to the link relations returned by LRDD, also query for these remote link relations".

I'm not sure if such a link relation has been defined, but I was thinking something like this:

<Link rel="external" href="http://www.example.org/paulej/links.xrds"/>

I'm not particularly fond of the word "external", but I cannot think of a better one off-hand.

I can think of two uses for this:
1) The Webfinger server can allow the user to augment link relations of his/her own
2) The Webfinger server can allow device management software to go query devices directly for link relations (the magic of how the Webfinger server becomes aware of the device's "external" URI is another matter... but we can solve that problem somehow)

Do others see value in an "external" link relation?

Paul

[Michiel de Jong]

alternatives to rel="external" could maybe be rel="lrdd" or rel="me". people are already using rel="me" to link to other files, i think. but if people start putting different parts of their profiles behind different links, then clients need to be forced to follow such links. so i think it's preferable if your whole lrdd profile is in one file where you, as a user, have a way of easily adding and removing links.

i have been playing with the idea of setting up lrdd hosting as a service, so people could point their host-meta file to it, and that way it would be less work for small domains to give good, compliant, cross-domain, and above all user-editable webfinger to their users. this service would obviously be open source, so people can at any point decide to move it to their own server, but i think it would help for people who just quickly want to try out webfinger.

In any case, if your identity is a gmail address, then right now there is no way for you as a user to control that identity in the sense of adding links to it. the easiest implementation of 'identity liberation' would i think be if a user gets one editable option, which is "host your lrdd somewhere else". Although your identity provider would probably prefer to keep the option to announce things about you on your behalf, so your suggestion of only linking additional entries may be more popular with identity providers (i'm guessing, here).

So yeah, i don't know what the right answer is. :)


cheers,
Michiel

[elf Pavlik]

Excerpts from John Panzer's message of 2012-01-08 03:41:10 +0000:
> rel="canonical"?
nice! it also seams useful if we try to merge content of multiple related LRDD where properties from canonical could have precedence...

looking at XRD spec: http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html
and JRD: https://tools.ietf.org/html/draft-hammer-hostmeta-17#appendix-A
it has <Expires> element and maybe together with rel="canonical" it would give us sort of a redirect?

i would like if we could find place in a spec for some recommendation on 'redirection' to new location of LRDD and maybe on merging multiple ones (cc Paul)

[elf Pavlik]

Excerpts from Michiel de Jong's message of 2012-01-07 23:21:52 +0000:

> i think a http redirect would be correct way to delegate authority, and
> should be supported by clients as part of 'fetching the file using
> http(s)'.

i find very handy in webfinger that you can set it up for yourself even with just 2 static files
.well-known/host-meta + your LRDD
this way one can write it by hand, or use some 'online generator' and than just upload it to your website =)

need for HTTP redirect could add little more complexity...

[Paul E. Jones]

The use of 3xx is already specified in the host-meta spec (RFC 6415). We could reinforce that with a redundant statement in the Webfinger draft and/or we could make it mandatory. (I'm not sure why it is a "SHOULD" in the host-meta document, as I would most certainly follow redirections.)

The "canonical" link relation was not intended for redirection, but for helping to define the most preferred URI out of several similar ones. For example, one could access my blog using two different, but similar, URIs. Use of "canonical" would instruct software interested to know (e.g., Google's search engine) which URI is preferred. I don't see it as useful for redirecting. I would use 3xx.

Paul

> > > On Sun, Jan 8, 2012 at 3:14 AM, elf Pavlik <perpetual-
> tri...@wwelves.org>wrote:

[elf Pavlik]

Excerpts from Paul E. Jones's message of 2012-01-08 23:05:08 +0000:

> The use of 3xx is already specified in the host-meta spec (RFC 6415). We could reinforce that with a redundant statement in the Webfinger draft and/or we could make it mandatory. (I'm not sure why it is a "SHOULD" in the host-meta document, as I would most certainly follow redirections.)

https://tools.ietf.org/html/rfc6415#section-4.2 paragraph 3.1
seams to have 'MUST'

>
> The "canonical" link relation was not intended for redirection, but for helping to define the most preferred URI out of several similar ones. For example, one could access my blog using two different, but similar, URIs. Use of "canonical" would instruct software interested to know (e.g., Google's search engine) which URI is preferred. I don't see it as useful for redirecting. I would use 3xx.

using the 3xx redirection this way i somehow see more as a tool for platform developers / admins to do plumbing in the app...

in the case i've described a person wants to state deprication of given webfinger identifier and association with new one most likely on different domain. i would rather look for a way that person can put this information in a depricated LRDD file, possibly by using <Property> and/or <Link> referencing new webfinger identifier.

once more stating that i changed my webfinger identifier and not just that the LRDD file resides now somewhere else, i might have brought some confusion with referencing HTTP 301 redirect =(

[Paul E. Jones]

Thus spake elf Pavlik

> Excerpts from Michiel de Jong's message of 2012-01-07 23:21:52 +0000:
> > i think a http redirect would be correct way to delegate authority,
> > and should be supported by clients as part of 'fetching the file using
> > http(s)'.
> i find very handy in webfinger that you can set it up for yourself even
> with just 2 static files .well-known/host-meta + your LRDD this way one
> can write it by hand, or use some 'online generator' and than just
> upload it to your website =)
>
> need for HTTP redirect could add little more complexity...

But this is the way the web works. 3xx responses are used all over the place. Browsers handle them automatically. Most libraries that handle HTTP requests do.

Paul

[Paul E. Jones]

I think ‘lrdd’ might be the right choice.  As a part of the registration with IANA that Eran and Blaine did, they opened up this possibility.  Form the host-meta RFC referring to LRDD:

 

Refers to further information about the link's context, expressed as a LRDD ("Link-based Resource Descriptor Document") resource.  See RFC 6415 for information about processing this relation type in host-meta documents.  When used elsewhere, it refers to additional links and other metadata.  Multiple instances indicate additional LRDD resources.  LRDD resources MUST have an "application/xrd+xml" representation, and MAY have others.

 

Assuming this means we could use an “href” type (rather than “template”) in the XRD that comes back from the first LRDD query, then we could use this type to refer to other locations.

 

One of the reasons why it’s hard for any providers of Webfinger to offer an external location is that the typical user would not know how to use it.  It would present all kinds of end-user support challenges.  However, I do think it would be a powerful tool for administrators and those who build tools for Webfinger.

 

One reason I use my own domain name is so that I can control my own identity.  I can implement my own Webfinger logic, OpenID server, etc.  And I did.  But, the typical user cannot do that.   So, if you want to offer external LRDD information, you’d have to find a way to present it to the user in terms he/she can understand.  I think that’s the hardest part to all of this.

 

Paul

[Paul E. Jones]

> in the case i've described a person wants to state deprication of given
> webfinger identifier and association with new one most likely on
> different domain. i would rather look for a way that person can put this
> information in a depricated LRDD file, possibly by using <Property>
> and/or <Link> referencing new webfinger identifier.

That makes sense, but it is counter to how things work on the web. If you create a web page and then move it to a new permenant location, we know that because the server returns a 301. Why not use that?

> once more stating that i changed my webfinger identifier and not just
> that the LRDD file resides now somewhere else, i might have brought some
> confusion with referencing HTTP 301 redirect =(

Changing an identifier and moving the location where LRDD link relations are served are two separate things.

If you wish to change the location for which link relations for b...@example.com are served, then I think 301 (or one of the other 3xx responses) is appropriate.

If you want to tell the world that b...@example.com is no longer valid and that people can find you at b...@example.org, then it does make sense to define some <Property/> that would indicate that fact. This would be immensely helpful for spammers looking to track ... never mind. Seriously, it would be useful ;) As things are today, if I change my email address, there is no way for me to reasonably inform everybody. This would be a good way of informing users of a change in address.

Paul

[Laurent-Walter Goix]

I tend to agree that 301 should be used only for pointing to another
Web uri where to find the xrd for that same resource.
In case of portability, user's new URL should be provided someway in
the xrd itself. Service providers may use their own way to allow the
user to input this info if he'd like, but from the spec perspective a
placeholder should be available.

I guess fundamentally there may be 2 options in the xrd/lrdd file to
accommodate this info:
- the Alias element, that could contain the 'new' acct uri. Maybe the
webfinger spec could provide some guidelines on how to treat this
element.
- a dedicated Link rel to contain the new acct uri itself . however i
would avoid an lrdd link rel as it should point to a web URL/template
that describes the acct: uri in the case, and this should not contain
the acct uri itself


There is a semantic difference according to XRD spec between both
options:
- "The <Alias> element contains a URI value that is an additional
identifier for the resource described by the XRD."
- "The <Link> element serves as a container for metadata about a
relation between the resource described by the XRD and a related
resource."

hence, depending on what we consider a "resource" the alias seems more
appropriate here (considering the physical person as resource), as the
main interest (for users and system implementations) is to find out
the new identity of the user. based on this+webfinger the new lrdd can
be found. i can understand a shortcut could be to directly reference
the new lrdd file/link but as end-user it may be difficult to figure
out, and it would give more flexibility to any system to feel free to
trigger webfinger again or not on the new identity... in other words,
if the old server performs the webfinger query on behalf of the user's
new identity to provide the link to the new lrdd directly in the old
lrdd, we loose flexibility or chances for updates etc.
in alternative (ie if the new identity is considered a different
resource than the old one), then the link is more appropriate, and
probably requires a new rel type to accomodate a user identity as url
and not the url of the xrd descriptor for that identity

thoughts?
walter

[elf Pavlik]

Excerpts from Laurent-Walter Goix's message of 2012-01-10 14:51:51 +0000:

how about first using <Expires> element to state obsolescence
and than just adding new URI in <Alias> element and recommending removing all other elements to only keep

<?xml version='1.0'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Subject>acct:depri...@example.com</Subject>
<Expires>2002-05-30T09:00:00</Expires> <!-- DATE IN A PAST -->
<Alias>acct:my-n...@example.net</Alias>
</XRD>

i see still little contradiction in honoring information in a document marked as expired...
or maybe we can just crate a new <Property> element with type for example 'http://webfinger.net/prop/redirect'

<?xml version='1.0'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Subject>acct:depri...@example.com</Subject>
<Property type='http://webfinger.net/prop/redirect'>acct:my-n...@example.com</Property>
</XRD>

we could also consider using <Link rel="current"> instead of giving Property a value...

~ elf pavlik ~

[Laurent-Walter Goix]

i would slightly prefer your first proposal on the <Alias> + <Expires>
as we are relating to another identifier for that resource, not to an
additional information about it. but of course this is tiny.

let's see what others/authors like more...

>   <Subject>acct:deprica...@example.com</Subject>

>   <Expires>2002-05-30T09:00:00</Expires> <!-- DATE IN A PAST -->

>   <Alias>acct:my-new...@example.net</Alias>

> </XRD>
>
> i see still little contradiction in honoring information in a document marked as expired...
> or maybe we can just crate a new <Property> element with type for example 'http://webfinger.net/prop/redirect'
>
> <?xml version='1.0'?>
> <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>

>   <Subject>acct:deprica...@example.com</Subject>
>   <Property type='http://webfinger.net/prop/redirect'>acct:my-new...@example.com</Property>