Possibly speeding up the RFC process
Melvin Carvalho
It seems to me that there are two value added use cases that have remained constant from the start.
1) Lookup of a string of type user@host to produce a HTTP URL
2) Lookup of a string of type mailto:user@host to produce a HTTP URL
These are two things that would really be very useful, irrespective of all the other benefits that webfinger has to offer.
We're perhaps at a point where both of these two cases have a solution.
So maybe it may be an idea to tidy up the current RFC in the WG and mark it as informational in line with the following:
http://www.ietf.org/iesg/informational-vs-experimental.html
[[
An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process
]]
I'm speculating here that this would get webfinger shipped more quickly. Getting webfinger to IETF to recommendation level would appear to be a greater task. Perhaps adding months to the time line, and if i have understood correctly there's no guarantee that an RFC will make it to recommendation status.
Part of me wants webfinger to be the best spec it can be, and for quality to be really high, yet another part would like to see webfinger actually shipped asap, and to start using a stable form to complete the loop in discovering more information from email via HTTP. So, just putting the idea out there.
Paul E. Jones
Melvin,
Going this route is not going to address the issues people have. The draft is oh-so-very-close to completion. I think that folks are largely OK with the text, the procedures, and the data format. There are still editorial matters, but nothing controversial.
The only sticky issue is use of TLS or not. But it’s a big one and we ought to get this right.
Without requiring use of TLS, there exists the possibility that a person queries for “custome...@somebank.com” and a thief intercepts that request and provides bogus information. The user might trust that information, call a discovered phone number, and provide the thief with information that the thief can use to empty the user’s bank accounts.
Requiring TLS, though, is viewed as a roadblock to deployment. For sites where security simply is not that important, it is a valid question as to why TLS must be mandated.
Some clients are in the unfortunate position of not knowing whether security is or is not important for any given query. Some clients know, though. If I had software on my server that facilitates an OpenID login, it would know to use TLS only. My email client, though, does not know how important security is.
The current text that’s proposed allows the client to select the transport. I think that’s OK, but we just need to provide some additional guidance to client writers. Perhaps we even suggest that an indicator should be provided to the user so they will know if HTTPS was used to retrieve the data. But it would have to be ONLY HTTPS was used, as a promotion from HTTP to HTTPS cannot be trusted. The “visible trust” element is presently missing.
Anyway, I think working through that language might be a good compromise. Clients that need security will get it. Clients that do not care may or may not. Providing a visual indicator to the user, where appropriate, might help address the MITM attack concerns.
We just need to decide:
· HTTPS only
· Either HTTPS or HTTP (or both)
There are those firmly sitting on both sides and that’s the problem. We need to just pick a direction and go with it. Ironing out the wording is far less difficult than reaching agreement on the two choices.
Now to your plea to just get it done. Here’s what I suggest: how about we just say HTTPS only and publish it. Then, we could later introduce an HTTP fallback option via a separate or updated RFC. The issue with introducing HTTP as an option now is the security complexity. That’s really holding us up. So, if we table that issue and just go with HTTPS for the moment, we at least have a working solution that starts out as a secure solution. We could form a WG to hammer out how to soften the security requirements once we get the HTTPS-only version out the door. (There are other things I believe we probably need to tackle as a part of that WG, such as definition of properties, new “rel” values, etc.)
Paul
Melvin Carvalho
Melvin,
Going this route is not going to address the issues people have. The draft is oh-so-very-close to completion. I think that folks are largely OK with the text, the procedures, and the data format. There are still editorial matters, but nothing controversial.
The only sticky issue is use of TLS or not. But it’s a big one and we ought to get this right.
Without requiring use of TLS, there exists the possibility that a person queries for “custome...@somebank.com” and a thief intercepts that request and provides bogus information. The user might trust that information, call a discovered phone number, and provide the thief with information that the thief can use to empty the user’s bank accounts.
Requiring TLS, though, is viewed as a roadblock to deployment. For sites where security simply is not that important, it is a valid question as to why TLS must be mandated.
Some clients are in the unfortunate position of not knowing whether security is or is not important for any given query. Some clients know, though. If I had software on my server that facilitates an OpenID login, it would know to use TLS only. My email client, though, does not know how important security is.
The current text that’s proposed allows the client to select the transport. I think that’s OK, but we just need to provide some additional guidance to client writers. Perhaps we even suggest that an indicator should be provided to the user so they will know if HTTPS was used to retrieve the data. But it would have to be ONLY HTTPS was used, as a promotion from HTTP to HTTPS cannot be trusted. The “visible trust” element is presently missing.
Anyway, I think working through that language might be a good compromise. Clients that need security will get it. Clients that do not care may or may not. Providing a visual indicator to the user, where appropriate, might help address the MITM attack concerns.
We just need to decide:
· HTTPS only
· Either HTTPS or HTTP (or both)
There are those firmly sitting on both sides and that’s the problem. We need to just pick a direction and go with it. Ironing out the wording is far less difficult than reaching agreement on the two choices.
Now to your plea to just get it done. Here’s what I suggest: how about we just say HTTPS only and publish it. Then, we could later introduce an HTTP fallback option via a separate or updated RFC. The issue with introducing HTTP as an option now is the security complexity. That’s really holding us up. So, if we table that issue and just go with HTTPS for the moment, we at least have a working solution that starts out as a secure solution. We could form a WG to hammer out how to soften the security requirements once we get the HTTPS-only version out the door. (There are other things I believe we probably need to tackle as a part of that WG, such as definition of properties, new “rel” values, etc.)
Paul, thanks for the detailed response.
Re: the HTTP/HTTPS debate, I'm really supportive of whatever will allow consensus to be reached fastest. Today I ordered my StartSSL certificate, so hopefully I can do my little bit too :)
However, that is not the greatest of the concerns that I have seen. The most serious critique I've seen to date is the thread form Mark Nottingham, "Looking at Webfinger"
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06487.html
In particular:
[[
Astute observers will notice that this approach removes the need for an ACCT URI scheme (at least here).
* What's the fascination with XRD and JRD? These specifications seem to be creeping into IETF architecture; first it was in a pure security context, but now folks are talking about using them in a much more generic way, as a cornerstone of what we do. As such, I think they deserve a MUCH closer look, especially since we're defining things with "Web" in their name when the W3C has already defined solutions in this space.
]]
Mark Nottingham has a stellar reputation at the IETF, and these are some of the more serious concerns raised to date, imho, and have yet to be fully addressed. And that may take some time to work through.
If perhaps going the "informational" route could save a significant amount of time, say, 6 months or a year, do you think would it be worth considering?
Paul E. Jones
Melvin,
Most of those issues have been addressed. We’ve divorced WF from Hostmeta. XRD is no longer used. We are using JRD, but I see no good reason to exchange it. It’s six of one, half a dozen of anther when it comes to a format like that. JRD is clean and it has some nice properties about it that allow us to do things like are shown in the examples. I think the biggest concern people had was the need to go read RFC 6415 or the XRD spec. We’ve addressed that by documenting JRD entirely within the WF spec itself.
Paul
From: webfinge...@ietf.org [mailto:webfinge...@ietf.org] On Behalf Of Melvin Carvalho
Sent: Sunday, December 16, 2012 4:01 PM
To: webf...@googlegroups.com
Cc: webf...@ietf.org
Subject: Re: [webfinger] Possibly speeding up the RFC process
[snip]
Re: the HTTP/HTTPS debate, I'm really supportive of whatever will allow consensus to be reached fastest. Today I ordered my StartSSL certificate, so hopefully I can do my little bit too :)
However, that is not the greatest of the concerns that I have seen. The most serious critique I've seen to date is the thread form Mark Nottingham, "Looking at Webfinger"
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06487.html
In particular:
[[
Astute observers will notice that this approach removes the need for an ACCT URI scheme (at least here).
* What's the fascination with XRD and JRD? These specifications seem to be creeping into IETF architecture; first it was in a pure security context, but now folks are talking about using them in a much more generic way, as a cornerstone of what we do. As such, I think they deserve a MUCH closer look, especially since we're defining things with "Web" in their name when the W3C has already defined solutions in this space.
]]
Mark Nottingham has a stellar reputation at the IETF, and these are some of the more serious concerns raised to date, imho, and have yet to be fully addressed. And that may take some time to work through.
If perhaps going the "informational" route could save a significant amount of time, say, 6 months or a year, do you think would it be worth considering?
Paul
From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On Behalf Of Melvin Carvalho
Sent: Sunday, December 16, 2012 10:08 AM
To: webf...@googlegroups.com
Subject: Possibly speeding up the RFC process
Webfinger is now in it's 4th year and I think everyone would agree that we are keen to see it shipped
It seems to me that there are two value added use cases that have remained constant from the start.
1) Lookup of a string of type user@host to produce a HTTP URL
2) Lookup of a string of type mailto:user@host to produce a HTTP URL
These are two things that would really be very useful, irrespective of all the other benefits that webfinger has to offer.
We're perhaps at a point where both of these two cases have a solution.
So maybe it may be an idea to tidy up the current RFC in the WG and mark it as informational in line with the following:
http://www.ietf.org/iesg/informational-vs-experimental.html
[[
An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process
]]
I'm speculating here that this would get webfinger shipped more quickly. Getting webfinger to IETF to recommendation level would appear to be a greater task. Perhaps adding months to the time line, and if i have understood correctly there's no guarantee that an RFC will make it to recommendation status.
Part of me wants webfinger to be the best spec it can be, and for quality to be really high, yet another part would like to see webfinger actually shipped asap, and to start using a stable form to complete the loop in discovering more information from email via HTTP. So, just putting the idea out there.
[snip]
Melvin Carvalho
Melvin,
Most of those issues have been addressed. We’ve divorced WF from Hostmeta. XRD is no longer used. We are using JRD, but I see no good reason to exchange it. It’s six of one, half a dozen of anther when it comes to a format like that. JRD is clean and it has some nice properties about it that allow us to do things like are shown in the examples. I think the biggest concern people had was the need to go read RFC 6415 or the XRD spec. We’ve addressed that by documenting JRD entirely within the WF spec itself.
Yes, I did note that those changes were made, and I particularly like the move from XML to JSON.
I could be mistaken, but I am unsure that that all of the concerns will have been addressed to the satisfaction of the IESG.
The ones I noted:
- Should webfinger use the acct: scheme rather than simply a query parameter. This strikes me as a 'vanity' URI scheme. Aesthetics are important, but I'm unsure how popular a choice that will be with the IETF.
- JRD does not allow an array of items/subjects to be rendered in response to an HTTP request, whereas other serializations do allow that. This leads to an interoperability issue.
- Concerns were raised over the IPR of XRD/JRD. IANAL, but to the best of my knowledge they are not creative commons, or royalty free under, say, IETF / W3C / ISO. This topic would be well outside my area of expertize, but something the IETF may look at.
- Could webfinger be recommended as a best practice if the scope is sufficiently wide, to overlap in areas where the W3C has already standardized. Namely those of discovery via http (aka linked data) etc.
I accept that some or all of these concerns may be invalid, but as webfinger draws nearer to the standards track, perhaps it is possible that more people upstream could weigh in.
Paul E. Jones
Melvin,
Comments are in inline:
From: Melvin Carvalho [mailto:melvinc...@gmail.com]
Sent: Sunday, December 16, 2012 4:38 PM
To: Paul E. Jones
Cc: webf...@googlegroups.com; webf...@ietf.org
Subject: Re: [webfinger] Possibly speeding up the RFC process
On 16 December 2012 22:27, Paul E. Jones <pau...@packetizer.com> wrote:
Melvin,
Most of those issues have been addressed. We’ve divorced WF from Hostmeta. XRD is no longer used. We are using JRD, but I see no good reason to exchange it. It’s six of one, half a dozen of anther when it comes to a format like that. JRD is clean and it has some nice properties about it that allow us to do things like are shown in the examples. I think the biggest concern people had was the need to go read RFC 6415 or the XRD spec. We’ve addressed that by documenting JRD entirely within the WF spec itself.
Yes, I did note that those changes were made, and I particularly like the move from XML to JSON.
I could be mistaken, but I am unsure that that all of the concerns will have been addressed to the satisfaction of the IESG.
The ones I noted:
- Should webfinger use the acct: scheme rather than simply a query parameter. This strikes me as a 'vanity' URI scheme. Aesthetics are important, but I'm unsure how popular a choice that will be with the IETF.
PEJ: WebFinger uses any URI scheme. The “acct” scheme is just one of them and is not core to the spec now, though there is a statement recommending its use to identify accounts. That is its purpose and the “acct” URI, and it’s a valid purpose. The one example I like to give is “How do we identify an account at Twitter?” There is no email, so “mailto” is not the right URI. A user has an account at any service provider and the “acct” URI would identify the account, not the particular service at the service provider (e.g., email, XMPP, or whatever).
- JRD does not allow an array of items/subjects to be rendered in response to an HTTP request, whereas other serializations do allow that. This leads to an interoperability issue.
PEJ: I don’t understand your concern. If I query my server, I get an array of link relations. I can step through those sequentially to find what I’m looking for. If I want to arrange the data different, I could. There was a proposal, for example, to allow the “rel” value be the key that refers to an array of possible values. That works, but the issue is that we lose useful constructs like “properties”, “titles”, etc., unless we have keys that point to arrays of objects. This can get syntactically ugly. I personally like the way JRD is defined: it’s simple and clean. It definitely does not present interoperability issues. An interop problem exists when two devices implanting the same thing do it differently. If you implement JRD, there is no interop issue. JRD is JRD as defined entirely in the WF spec. People have been able to use it just fine so far.
- Concerns were raised over the IPR of XRD/JRD. IANAL, but to the best of my knowledge they are not creative commons, or royalty free under, say, IETF / W3C / ISO. This topic would be well outside my area of expertize, but something the IETF may look at.
PEJ: It has been said before that there were IPR claims on XRI. I’ve never heard an IPR claim on XRD, though. And JRD is an entirely different syntax defined within the IETF (Eran, specifically). If there are IPR claims on JRD, then it must have something to do with very high-level concepts for which there would be no way to escape, such as the notion of defining a “document” that contains “links” and “metadata” or something – like HTML. Until an IPR statement is filed, I think we can ignore this. Anything we would consider might fall into the realm of somebody’s IPR, so there’s no point worrying about it without solid evidence.
- Could webfinger be recommended as a best practice if the scope is sufficiently wide, to overlap in areas where the W3C has already standardized. Namely those of discovery via http (aka linked data) etc.
PEJ: I’m not sure what you are asking here.
Paul
Melvin Carvalho
Melvin,
Comments are in inline:
From: Melvin Carvalho [mailto:melvinc...@gmail.com]
Sent: Sunday, December 16, 2012 4:38 PM
To: Paul E. Jones
Cc: webf...@googlegroups.com; webf...@ietf.org
Subject: Re: [webfinger] Possibly speeding up the RFC process
On 16 December 2012 22:27, Paul E. Jones <pau...@packetizer.com> wrote:
Melvin,
Most of those issues have been addressed. We’ve divorced WF from Hostmeta. XRD is no longer used. We are using JRD, but I see no good reason to exchange it. It’s six of one, half a dozen of anther when it comes to a format like that. JRD is clean and it has some nice properties about it that allow us to do things like are shown in the examples. I think the biggest concern people had was the need to go read RFC 6415 or the XRD spec. We’ve addressed that by documenting JRD entirely within the WF spec itself.
Yes, I did note that those changes were made, and I particularly like the move from XML to JSON.
I could be mistaken, but I am unsure that that all of the concerns will have been addressed to the satisfaction of the IESG.
The ones I noted:
- Should webfinger use the acct: scheme rather than simply a query parameter. This strikes me as a 'vanity' URI scheme. Aesthetics are important, but I'm unsure how popular a choice that will be with the IETF.
PEJ: WebFinger uses any URI scheme. The “acct” scheme is just one of them and is not core to the spec now, though there is a statement recommending its use to identify accounts. That is its purpose and the “acct” URI, and it’s a valid purpose. The one example I like to give is “How do we identify an account at Twitter?” There is no email, so “mailto” is not the right URI. A user has an account at any service provider and the “acct” URI would identify the account, not the particular service at the service provider (e.g., email, XMPP, or whatever).
It's great that acct: is almost completely decoupled from the spec.
Sure I do understand why acct: would be useful.
But Mark and others pointed out you could equally use
webfinger?acct=bob
or
/.well-known/user/bob
my own suggestion from February was
/@/bob
None of the above are as beautiful as acct: but the debate may arise this is worth creating a new uri scheme.
- JRD does not allow an array of items/subjects to be rendered in response to an HTTP request, whereas other serializations do allow that. This leads to an interoperability issue.
PEJ: I don’t understand your concern. If I query my server, I get an array of link relations. I can step through those sequentially to find what I’m looking for. If I want to arrange the data different, I could. There was a proposal, for example, to allow the “rel” value be the key that refers to an array of possible values. That works, but the issue is that we lose useful constructs like “properties”, “titles”, etc., unless we have keys that point to arrays of objects. This can get syntactically ugly. I personally like the way JRD is defined: it’s simple and clean. It definitely does not present interoperability issues. An interop problem exists when two devices implanting the same thing do it differently. If you implement JRD, there is no interop issue. JRD is JRD as defined entirely in the WF spec. People have been able to use it just fine so far.
The link relations contain 3 components. The subject, the predicate and the object. In other language the entity the attribute and the value. The Entity in this case would be @subject, the attribute would be the rel of the link, and the value would be the value of the link.
In almost every serialization I know, multiple subjects/entities are permissible, in an array of (say JSON) objects. In JRD there is a constraint limiting the serialization to exactly one entity/subject. This imho could be seen as a slight weakness, especially it it makes the serialization of choice not 100% interoperable with others more permissible serializations.
- Concerns were raised over the IPR of XRD/JRD. IANAL, but to the best of my knowledge they are not creative commons, or royalty free under, say, IETF / W3C / ISO. This topic would be well outside my area of expertize, but something the IETF may look at.
PEJ: It has been said before that there were IPR claims on XRI. I’ve never heard an IPR claim on XRD, though. And JRD is an entirely different syntax defined within the IETF (Eran, specifically). If there are IPR claims on JRD, then it must have something to do with very high-level concepts for which there would be no way to escape, such as the notion of defining a “document” that contains “links” and “metadata” or something – like HTML. Until an IPR statement is filed, I think we can ignore this. Anything we would consider might fall into the realm of somebody’s IPR, so there’s no point worrying about it without solid evidence.
If JRD is completely under the IETF IPR, that would be extremely cool. I was unaware of that, if you have a pointer that would be great.
- Could webfinger be recommended as a best practice if the scope is sufficiently wide, to overlap in areas where the W3C has already standardized. Namely those of discovery via http (aka linked data) etc.
PEJ: I’m not sure what you are asking here.
I think the point Mark was suggesting is that both webfinger and the w3c 'web stack' offer options for discovery. Namely the W3C has spent much of the last 10 years working on discovery based on HTTP identifiers. If webfinger becomes a general purpose discovery method for any URI, then there is a possible overlap, which may perhaps lead to further discussion.
As you point out, it's just speculation at this point. Tho my understanding of the IETF process is that they do tend to drill down into the details, so sometimes it doesnt hurt to be prepared, or have a plan B :)
Paul E. Jones
Melvin,
Comments inline again:
PEJ: WebFinger uses any URI scheme. The “acct” scheme is just one of them and is not core to the spec now, though there is a statement recommending its use to identify accounts. That is its purpose and the “acct” URI, and it’s a valid purpose. The one example I like to give is “How do we identify an account at Twitter?” There is no email, so “mailto” is not the right URI. A user has an account at any service provider and the “acct” URI would identify the account, not the particular service at the service provider (e.g., email, XMPP, or whatever).
It's great that acct: is almost completely decoupled from the spec.
Sure I do understand why acct: would be useful.
But Mark and others pointed out you could equally use
webfinger?acct=bob
or
/.well-known/user/bob
my own suggestion from February was
/@/bob
None of the above are as beautiful as acct: but the debate may arise this is worth creating a new uri scheme.
PEJ: Yeah, all of these are possibilities. The one thing that I personally think is important is that the “thing” we query is a URI. So, forms that do not utilize URIs I think we should not consider. There are several ways to utilize URIs and I think it comes down to putting the URI as a part of the path or using a URI parameter. We’re presently heading down the latter path. The disadvantage is that one cannot build a “truly” static site, though one can come close using Apache re-writing rules. That said, there is utility in the approach, since once can query for a specific URI and request the response to be filtered for a particular set of link relations (“rel” parameters). Thus, it’s making the web programmable. I think we’re past that debate now. I hope so.
- JRD does not allow an array of items/subjects to be rendered in response to an HTTP request, whereas other serializations do allow that. This leads to an interoperability issue.
PEJ: I don’t understand your concern. If I query my server, I get an array of link relations. I can step through those sequentially to find what I’m looking for. If I want to arrange the data different, I could. There was a proposal, for example, to allow the “rel” value be the key that refers to an array of possible values. That works, but the issue is that we lose useful constructs like “properties”, “titles”, etc., unless we have keys that point to arrays of objects. This can get syntactically ugly. I personally like the way JRD is defined: it’s simple and clean. It definitely does not present interoperability issues. An interop problem exists when two devices implanting the same thing do it differently. If you implement JRD, there is no interop issue. JRD is JRD as defined entirely in the WF spec. People have been able to use it just fine so far.
The link relations contain 3 components. The subject, the predicate and the object. In other language the entity the attribute and the value. The Entity in this case would be @subject, the attribute would be the rel of the link, and the value would be the value of the link.
In almost every serialization I know, multiple subjects/entities are permissible, in an array of (say JSON) objects. In JRD there is a constraint limiting the serialization to exactly one entity/subject. This imho could be seen as a slight weakness, especially it it makes the serialization of choice not 100% interoperable with others more permissible serializations.
PEJ: My understanding of subject is the “thing” I’m querying (e.g., acct:pau...@packetizer.com). Given that definition, JRD covers a single subject since WF is looking for a single “thing”. Inside, there may be multiple “properties” for the “thing” (e.g., “http://packetizer.com/ns/name” is a property with a value “Paul E. Jones). Then there is an array of “link relations”. The definition follows that of RFC 5988. Each link relation is identified by a “rel” value. There is also an optional “type”. And there is an “href”. JRD also allows for self-describing link relations, where the “href” is absent and “properties” are used to describe the value of the relation to the “rel”. An example is this: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.3. Lastly, any link may have one or more human-readable names in a “titles” array. You can see an example here:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.1.
- Concerns were raised over the IPR of XRD/JRD. IANAL, but to the best of my knowledge they are not creative commons, or royalty free under, say, IETF / W3C / ISO. This topic would be well outside my area of expertize, but something the IETF may look at.
PEJ: It has been said before that there were IPR claims on XRI. I’ve never heard an IPR claim on XRD, though. And JRD is an entirely different syntax defined within the IETF (Eran, specifically). If there are IPR claims on JRD, then it must have something to do with very high-level concepts for which there would be no way to escape, such as the notion of defining a “document” that contains “links” and “metadata” or something – like HTML. Until an IPR statement is filed, I think we can ignore this. Anything we would consider might fall into the realm of somebody’s IPR, so there’s no point worrying about it without solid evidence.
If JRD is completely under the IETF IPR, that would be extremely cool. I was unaware of that, if you have a pointer that would be great.
PEJ: I didn’t say that, only that JRD was entirely documented in an IETF document (RFC 6415). The syntax was derived from XRD, though. I’m just not aware of any IPR claims on XRD, and whatever is claimed may or may not apply to JRD (since it is a different syntax). As I said, it would have to be a pretty broad, generic claim.
- Could webfinger be recommended as a best practice if the scope is sufficiently wide, to overlap in areas where the W3C has already standardized. Namely those of discovery via http (aka linked data) etc.
PEJ: I’m not sure what you are asking here.
I think the point Mark was suggesting is that both webfinger and the w3c 'web stack' offer options for discovery. Namely the W3C has spent much of the last 10 years working on discovery based on HTTP identifiers. If webfinger becomes a general purpose discovery method for any URI, then there is a possible overlap, which may perhaps lead to further discussion.
PEJ: WebFinger is narrowly defined. If there is another standard doing exactly the same thing with the same level of simplicity, I think it would have been adopted already. There are certainly other kinds of “discovery” protocols, but each that I have seen has a different scope, complexity, value, etc. The support for WF has been pretty strong thus far. I cannot say it will be the recommended best practice, though. We’ll have to see what the adoption rate looks like.
As you point out, it's just speculation at this point. Tho my understanding of the IETF process is that they do tend to drill down into the details, so sometimes it doesnt hurt to be prepared, or have a plan B :)
PEJ: I’m too tired for a Plan B. WebFinger started as a spec with a lot of stuff inside and we’ve thrown out lots of options. We’re now down to this, a product of several years’ worth of work by multiple people. Once we settle on the HTTP/HTTPS issue, I hope we can say we’re finished (modulo less controversial editorial things). There will be a review process, but I would not expect that to result is significant technical changes.
Paul
Melvin Carvalho
Melvin,
Comments inline again:
PEJ: WebFinger uses any URI scheme. The “acct” scheme is just one of them and is not core to the spec now, though there is a statement recommending its use to identify accounts. That is its purpose and the “acct” URI, and it’s a valid purpose. The one example I like to give is “How do we identify an account at Twitter?” There is no email, so “mailto” is not the right URI. A user has an account at any service provider and the “acct” URI would identify the account, not the particular service at the service provider (e.g., email, XMPP, or whatever).
It's great that acct: is almost completely decoupled from the spec.
Sure I do understand why acct: would be useful.
But Mark and others pointed out you could equally use
webfinger?acct=bob
or
/.well-known/user/bob
my own suggestion from February was
/@/bob
None of the above are as beautiful as acct: but the debate may arise this is worth creating a new uri scheme.
PEJ: Yeah, all of these are possibilities. The one thing that I personally think is important is that the “thing” we query is a URI. So, forms that do not utilize URIs I think we should not consider. There are several ways to utilize URIs and I think it comes down to putting the URI as a part of the path or using a URI parameter. We’re presently heading down the latter path. The disadvantage is that one cannot build a “truly” static site, though one can come close using Apache re-writing rules. That said, there is utility in the approach, since once can query for a specific URI and request the response to be filtered for a particular set of link relations (“rel” parameters). Thus, it’s making the web programmable. I think we’re past that debate now. I hope so.
Sure, but query parameters can take URIs too, SWD did, for example.
- JRD does not allow an array of items/subjects to be rendered in response to an HTTP request, whereas other serializations do allow that. This leads to an interoperability issue.
PEJ: I don’t understand your concern. If I query my server, I get an array of link relations. I can step through those sequentially to find what I’m looking for. If I want to arrange the data different, I could. There was a proposal, for example, to allow the “rel” value be the key that refers to an array of possible values. That works, but the issue is that we lose useful constructs like “properties”, “titles”, etc., unless we have keys that point to arrays of objects. This can get syntactically ugly. I personally like the way JRD is defined: it’s simple and clean. It definitely does not present interoperability issues. An interop problem exists when two devices implanting the same thing do it differently. If you implement JRD, there is no interop issue. JRD is JRD as defined entirely in the WF spec. People have been able to use it just fine so far.
The link relations contain 3 components. The subject, the predicate and the object. In other language the entity the attribute and the value. The Entity in this case would be @subject, the attribute would be the rel of the link, and the value would be the value of the link.
In almost every serialization I know, multiple subjects/entities are permissible, in an array of (say JSON) objects. In JRD there is a constraint limiting the serialization to exactly one entity/subject. This imho could be seen as a slight weakness, especially it it makes the serialization of choice not 100% interoperable with others more permissible serializations.
PEJ: My understanding of subject is the “thing” I’m querying (e.g., acct:pau...@packetizer.com). Given that definition, JRD covers a single subject since WF is looking for a single “thing”. Inside, there may be multiple “properties” for the “thing” (e.g., “http://packetizer.com/ns/name” is a property with a value “Paul E. Jones). Then there is an array of “link relations”. The definition follows that of RFC 5988. Each link relation is identified by a “rel” value. There is also an optional “type”. And there is an “href”. JRD also allows for self-describing link relations, where the “href” is absent and “properties” are used to describe the value of the relation to the “rel”. An example is this: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.3. Lastly, any link may have one or more human-readable names in a “titles” array. You can see an example here:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.1.
- Concerns were raised over the IPR of XRD/JRD. IANAL, but to the best of my knowledge they are not creative commons, or royalty free under, say, IETF / W3C / ISO. This topic would be well outside my area of expertize, but something the IETF may look at.
PEJ: It has been said before that there were IPR claims on XRI. I’ve never heard an IPR claim on XRD, though. And JRD is an entirely different syntax defined within the IETF (Eran, specifically). If there are IPR claims on JRD, then it must have something to do with very high-level concepts for which there would be no way to escape, such as the notion of defining a “document” that contains “links” and “metadata” or something – like HTML. Until an IPR statement is filed, I think we can ignore this. Anything we would consider might fall into the realm of somebody’s IPR, so there’s no point worrying about it without solid evidence.
If JRD is completely under the IETF IPR, that would be extremely cool. I was unaware of that, if you have a pointer that would be great.
PEJ: I didn’t say that, only that JRD was entirely documented in an IETF document (RFC 6415). The syntax was derived from XRD, though. I’m just not aware of any IPR claims on XRD, and whatever is claimed may or may not apply to JRD (since it is a different syntax). As I said, it would have to be a pretty broad, generic claim.
This is outside of my scope of expertize. I couldnt really comment further, tho others may.
- Could webfinger be recommended as a best practice if the scope is sufficiently wide, to overlap in areas where the W3C has already standardized. Namely those of discovery via http (aka linked data) etc.
PEJ: I’m not sure what you are asking here.
I think the point Mark was suggesting is that both webfinger and the w3c 'web stack' offer options for discovery. Namely the W3C has spent much of the last 10 years working on discovery based on HTTP identifiers. If webfinger becomes a general purpose discovery method for any URI, then there is a possible overlap, which may perhaps lead to further discussion.
PEJ: WebFinger is narrowly defined. If there is another standard doing exactly the same thing with the same level of simplicity, I think it would have been adopted already. There are certainly other kinds of “discovery” protocols, but each that I have seen has a different scope, complexity, value, etc. The support for WF has been pretty strong thus far. I cannot say it will be the recommended best practice, though. We’ll have to see what the adoption rate looks like.
Well linked data is adopted by many of the G7 govts., the world bank, cities, fire deparments, 1000s of businesses, academia, search engines and grass roots.
As you point out, it's just speculation at this point. Tho my understanding of the IETF process is that they do tend to drill down into the details, so sometimes it doesnt hurt to be prepared, or have a plan B :)
PEJ: I’m too tired for a Plan B. WebFinger started as a spec with a lot of stuff inside and we’ve thrown out lots of options. We’re now down to this, a product of several years’ worth of work by multiple people. Once we settle on the HTTP/HTTPS issue, I hope we can say we’re finished (modulo less controversial editorial things). There will be a review process, but I would not expect that to result is significant technical changes.
Sure I appreciate the effort you've put in here. I'm just saying, as per my original post, that if there is pushback, it may be expedient to switch to "informational" status, as it would seemingly not have a big impact on implementers. As I said, just an idea, let's see how the spec is received after the HTTPS issue is resolved.
Paul
Melvin Carvalho
On 17 December 2012 00:21, Paul E. Jones <pau...@packetizer.com> wrote:Melvin,
Comments inline again:
PEJ: WebFinger uses any URI scheme. The “acct” scheme is just one of them and is not core to the spec now, though there is a statement recommending its use to identify accounts. That is its purpose and the “acct” URI, and it’s a valid purpose. The one example I like to give is “How do we identify an account at Twitter?” There is no email, so “mailto” is not the right URI. A user has an account at any service provider and the “acct” URI would identify the account, not the particular service at the service provider (e.g., email, XMPP, or whatever).
It's great that acct: is almost completely decoupled from the spec.
Sure I do understand why acct: would be useful.
But Mark and others pointed out you could equally use
webfinger?acct=bob
or
/.well-known/user/bob
my own suggestion from February was
/@/bob
None of the above are as beautiful as acct: but the debate may arise this is worth creating a new uri scheme.
PEJ: Yeah, all of these are possibilities. The one thing that I personally think is important is that the “thing” we query is a URI. So, forms that do not utilize URIs I think we should not consider. There are several ways to utilize URIs and I think it comes down to putting the URI as a part of the path or using a URI parameter. We’re presently heading down the latter path. The disadvantage is that one cannot build a “truly” static site, though one can come close using Apache re-writing rules. That said, there is utility in the approach, since once can query for a specific URI and request the response to be filtered for a particular set of link relations (“rel” parameters). Thus, it’s making the web programmable. I think we’re past that debate now. I hope so.
Sure, but query parameters can take URIs too, SWD did, for example.
- JRD does not allow an array of items/subjects to be rendered in response to an HTTP request, whereas other serializations do allow that. This leads to an interoperability issue.
PEJ: I don’t understand your concern. If I query my server, I get an array of link relations. I can step through those sequentially to find what I’m looking for. If I want to arrange the data different, I could. There was a proposal, for example, to allow the “rel” value be the key that refers to an array of possible values. That works, but the issue is that we lose useful constructs like “properties”, “titles”, etc., unless we have keys that point to arrays of objects. This can get syntactically ugly. I personally like the way JRD is defined: it’s simple and clean. It definitely does not present interoperability issues. An interop problem exists when two devices implanting the same thing do it differently. If you implement JRD, there is no interop issue. JRD is JRD as defined entirely in the WF spec. People have been able to use it just fine so far.
The link relations contain 3 components. The subject, the predicate and the object. In other language the entity the attribute and the value. The Entity in this case would be @subject, the attribute would be the rel of the link, and the value would be the value of the link.
In almost every serialization I know, multiple subjects/entities are permissible, in an array of (say JSON) objects. In JRD there is a constraint limiting the serialization to exactly one entity/subject. This imho could be seen as a slight weakness, especially it it makes the serialization of choice not 100% interoperable with others more permissible serializations.
PEJ: My understanding of subject is the “thing” I’m querying (e.g., acct:pau...@packetizer.com). Given that definition, JRD covers a single subject since WF is looking for a single “thing”. Inside, there may be multiple “properties” for the “thing” (e.g., “http://packetizer.com/ns/name” is a property with a value “Paul E. Jones). Then there is an array of “link relations”. The definition follows that of RFC 5988. Each link relation is identified by a “rel” value. There is also an optional “type”. And there is an “href”. JRD also allows for self-describing link relations, where the “href” is absent and “properties” are used to describe the value of the relation to the “rel”. An example is this: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.3. Lastly, any link may have one or more human-readable names in a “titles” array. You can see an example here:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.1.
Sorry forgot to respond to this point. (only did the red ones :))
Thanks, I think I understand the JRD format and it's great that A) it's JSON based and B) it can be self describing and C) that it can include references (links) to other URIs
The weakness in this serialization is that it becomes tightly coupled to the query that generated it. A data document should be an entity in it's own right that is independent of how it is generated. What we are getting is data, that happened to be delivered via webfinger. While it is often the case on the web that a document will yield a single subject, and indeed in many cases this is a best practice, it is not always the case. There are many cases where there are multiple items in a single page, a good example is wikipedia which divides itself up into many sections; the page may be about Germany, then the sections could be about Geography, History, Economy etc. This leads to interoperability issues with the rest of the web.
My view is that webfinger should be serialization agnostic and operate using content negotiation. JRD is one of the weaker serializations, imho, and as mark has suggested, if favoured especially it will need greater review, which may take time. Im not sure anyone has ever answered the question as to why has it been consistently favoured?
Nick Jennings
> From: Melvin Carvalho [mailto:melvinc...@gmail.com]
> Sent: Sunday, December 16, 2012 4:38 PM
> To: Paul E. Jones
> Cc: webf...@googlegroups.com; webf...@ietf.org
> Subject: Re: [webfinger] Possibly speeding up the RFC process
>
> parameter. This strikes me as a 'vanity' URI scheme. Aesthetics are
> important, but I'm unsure how popular a choice that will be with the IETF.
>
>
> PEJ: WebFinger uses any URI scheme. The “acct” scheme is just one of them
> and is not core to the spec now, though there is a statement recommending
> its use to identify accounts. That is its purpose and the “acct” URI, and
> it’s a valid purpose. The one example I like to give is “How do we identify
> an account at Twitter?” There is no email, so “mailto” is not the right
> URI. A user has an account at any service provider and the “acct” URI would
> identify the account, not the particular service at the service provider
> (e.g., email, XMPP, or whatever).
>
not missing something.
Maybe I don't fully understand the various use-cases, but it seems
like you are saying that when querying a 'resource', the value does
NOT need to be prefixed with acct (or anything). I know there's the
idea that at some point another type of resource could be identified
as relevant and so that was the argument for having the 'acct' prefix.
However your wording suggests that even 'acct' is not needed. So
someone's WF service could accept 'resource=bob' and not
'resource=acct:b...@example.com' and it would still be a compliant WF
service? If true, it seems like there could be a lot of room for
uncertainty in query format and client libraries would have to try a
number of different value formats.
Another thing, in regards to the twitter example you gave. What's to
differentiate a user of twitter and an employee of twitter?
There could be a user '@janice' and an employee 'jan...@twitter.com',
who may be different people. As I understand it, in your example,
these different accounts would be queried in the same way.
/.host-meta/webfinger?resource=acct:jan...@twitter.com
Am I misunderstanding? Or does this create a problem.
-Nick
Paul E. Jones
Melvin,
Comments below:
The link relations contain 3 components. The subject, the predicate and the object. In other language the entity the attribute and the value. The Entity in this case would be @subject, the attribute would be the rel of the link, and the value would be the value of the link.
In almost every serialization I know, multiple subjects/entities are permissible, in an array of (say JSON) objects. In JRD there is a constraint limiting the serialization to exactly one entity/subject. This imho could be seen as a slight weakness, especially it it makes the serialization of choice not 100% interoperable with others more permissible serializations.
PEJ: My understanding of subject is the “thing” I’m querying (e.g., acct:pau...@packetizer.com). Given that definition, JRD covers a single subject since WF is looking for a single “thing”. Inside, there may be multiple “properties” for the “thing” (e.g., “http://packetizer.com/ns/name” is a property with a value “Paul E. Jones). Then there is an array of “link relations”. The definition follows that of RFC 5988. Each link relation is identified by a “rel” value. There is also an optional “type”. And there is an “href”. JRD also allows for self-describing link relations, where the “href” is absent and “properties” are used to describe the value of the relation to the “rel”. An example is this: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.3. Lastly, any link may have one or more human-readable names in a “titles” array. You can see an example here:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.1.
Sorry forgot to respond to this point. (only did the red ones :))
Thanks, I think I understand the JRD format and it's great that A) it's JSON based and B) it can be self describing and C) that it can include references (links) to other URIs
The weakness in this serialization is that it becomes tightly coupled to the query that generated it. A data document should be an entity in it's own right that is independent of how it is generated. What we are getting is data, that happened to be delivered via webfinger. While it is often the case on the web that a document will yield a single subject, and indeed in many cases this is a best practice, it is not always the case. There are many cases where there are multiple items in a single page, a good example is wikipedia which divides itself up into many sections; the page may be about Germany, then the sections could be about Geography, History, Economy etc. This leads to interoperability issues with the rest of the web.
My view is that webfinger should be serialization agnostic and operate using content negotiation. JRD is one of the weaker serializations, imho, and as mark has suggested, if favoured especially it will need greater review, which may take time. Im not sure anyone has ever answered the question as to why has it been consistently favoured?
PEJ: It is tightly coupled with the query, but view that as positive. JRD has a limited use. It’s not HTML where we’re creating elaborate documents. It’s a simple data structure that conveys link relations and properties about a “subject”. If one wanted to have a more complex document that included multiple “subjects”, one could create an array or hash table of JRDs. Such use, though, is entirely outside the scope of WebFinger. I do like use of content negotiation. Nothing precludes that from happening in WF, either, since it is built on top of HTTP. We’re just not specifying what would be negotiated. The current text says:
WebFinger servers MUST return a JRD as the representation for the resource if the client requests no format explicitly via the HTTP “Accept” header. A client MAY include the “Accept” header to indicate a desired representation, though no other representation is defined in this specification.
Melvin Carvalho
I dont know that much about JRD, but I'd just like to double check this point. Are you sure it is possible to create an array of JRDs?
My understanding was that in XRD this was forbidden. If it's possible in JRD, that would be a *major* plus, imho, because it would mean that at least *theoretically* the default webfinger serialization is interoperable with the rest of the web.
Paul E. Jones
> > PEJ: WebFinger uses any URI scheme. The “acct” scheme is just one of
> > them and is not core to the spec now, though there is a statement
> > recommending its use to identify accounts. That is its purpose and
> > the “acct” URI, and it’s a valid purpose. The one example I like to
> > give is “How do we identify an account at Twitter?” There is no
> > email, so “mailto” is not the right URI. A user has an account at any
> > service provider and the “acct” URI would identify the account, not
> > the particular service at the service provider (e.g., email, XMPP, or
> whatever).
> >
>
> Hi Paul, I just wanted to run a few thoughts by you to make sure I'm not
> missing something.
>
> Maybe I don't fully understand the various use-cases, but it seems like
> you are saying that when querying a 'resource', the value does NOT need
> to be prefixed with acct (or anything). I know there's the idea that at
> some point another type of resource could be identified as relevant and
> so that was the argument for having the 'acct' prefix.
> However your wording suggests that even 'acct' is not needed. So
> someone's WF service could accept 'resource=bob' and not
> 'resource=acct:b...@example.com' and it would still be a compliant WF
> service? If true, it seems like there could be a lot of room for
> uncertainty in query format and client libraries would have to try a
> number of different value formats.
My own server code actually will accept just "pau...@packetizer.com", for example. If it sees that, it assumes the requestor wants "acct:pau...@packetizer.com" and returns the results from the database for the "acct:" URI. However, the "subject" is just the bare "pau...@packetizer.com" and the "acct:" URI is inserted into the response as an alias. However, none of that is in the spec. I did that long ago, because Blaine preferred to not require a URI scheme for user@domain forms.
> Another thing, in regards to the twitter example you gave. What's to
> differentiate a user of twitter and an employee of twitter?
>
> There could be a user '@janice' and an employee 'jan...@twitter.com',
> who may be different people. As I understand it, in your example, these
> different accounts would be queried in the same way.
>
> /.host-meta/webfinger?resource=acct:jan...@twitter.com
On my own web site, I run phpBB. There are user accounts. So, I can appreciate how people get into that situation. However, I placed the discussion forms at forums.packetizer.com and so if the phpBB software ever supported WebFinger (hmmmm... more holiday coding opportunities) then I would expect it to respond only to acct:<user>@forums.packetizer.com. That would be perfectly fine and would avoid the name clash. WF does not require queries only to the domain. Queries can be sent to any appropriate host within the domain.
> Am I misunderstanding? Or does this create a problem.
Paul
Paul E. Jones
Melvin,
The JRD spec itself (and I’ve extracted it out and placed it here for convenience: http://www.packetizer.com/json/jrd/) does not define creating an array of itself.
However, programmatically it would be trivial to create an array of JRD objects in virtually any language. WebFinger only deals with a single “subject” at a time. So, the data returned from the server does not need to have multiple sections with a “subject” per section. However, since the “subject” is an element within the JRD, then you can imagine a JSON object like this:
{ “jrds” : [ { <jrd1> }, { <jrd2> }, { ... } ] }
or
{ “<jrd subject 1>” : { <jrd 1 }, “<jrd subject 2>”, { <jrd 2> }, ... }
Neither are defined, but you can see how JRDs could be used within more complex documents.
Paul
Melvin Carvalho
Melvin,
The JRD spec itself (and I’ve extracted it out and placed it here for convenience: http://www.packetizer.com/json/jrd/) does not define creating an array of itself.
However, programmatically it would be trivial to create an array of JRD objects in virtually any language. WebFinger only deals with a single “subject” at a time. So, the data returned from the server does not need to have multiple sections with a “subject” per section. However, since the “subject” is an element within the JRD, then you can imagine a JSON object like this:
{ “jrds” : [ { <jrd1> }, { <jrd2> }, { ... } ] }
or
{ “<jrd subject 1>” : { <jrd 1 }, “<jrd subject 2>”, { <jrd 2> }, ... }
Neither are defined, but you can see how JRDs could be used within more complex documents.
Sounds great
I think all you would need to do is
[
{ JRD1 },
{ JRD2 },
{ JRD3 }
]
See Example 51 from :
http://json-ld.org/spec/latest/json-ld-syntax/
The reason that I asked is that the XML Schema or XRD strictly forbids more than one object. I do not know the rationale for this, because other serializations definitely allow multiple.
If JRD can do this, that's a big plus. Thanks for extracting the spec. Do you know who maintains JRD currently?
Paul E. Jones
Melvin,
Yep, that syntax will work just fine if you want an array. I was thinking only about object syntax.
In any case, the JRD syntax is documented in the current WF spec. That’s where it will be cast into stone and I don’t expect any need for making changes to it once we’re finished. We ought not add more complexity to it than is already defined.
Paul
From: Melvin Carvalho [mailto:melvinc...@gmail.com]
Sent: Monday, December 17, 2012 4:36 PM
To: Paul E. Jones
Cc: webf...@googlegroups.com; webf...@ietf.org
Subject: Re: [webfinger] Possibly speeding up the RFC process
On 17 December 2012 22:04, Paul E. Jones <pau...@packetizer.com> wrote:
Nick Jennings
I've been giving this some more thought, if the person running the WF
service can make up their own system of identifying users (whatever
works for them), then in order to write a robust WF client, you're
going to have to do a lot of second guessing. I don't understand why
we have 'acct:' if (a) it's not required at all, and (b) it's
suggested we use the full 'us...@example.com' anyway, however (c) we
also don't have to do that...
In the case of that twitter example. If they wanted to solve this
issue, they might impose a system like:
/.host-meta/webfinger?resource=jan...@twitter.com
...that gets the record for the employee Janice
/.host-meta/webfinger?resource=acct:janice
...that gets the record for the user-account 'janice'
In this case 'acct' prefix referring to just the 'webapp' accounts,
and not 'admin/employee' accounts.
I think a clarification of what to use as the resource value to
signify whether we are, querying an email address (used by, for
example, and email client, or blog comments). or a user account (used
by, for example, phpBB, wordpress, twitter, etc.) would be really
helpful.
Otherwise we're going to have similar client complexity to the issues
we've already discussed regarding using fallback methods. though maybe
more complicated because we could have false positives if, for
example, jan...@twitter.com is queried for a user account but the
profile for the employee is returned.
Does anyone else see the ambiguity here as a potentially pretty bad problem?
-nick
Goix Laurent Walter
> Da: webf...@googlegroups.com [mailto:webf...@googlegroups.com] Per conto
> di Nick Jennings
> Inviato: martedì 18 dicembre 2012 20.37
> A: Paul E. Jones
> Cc: webf...@googlegroups.com; webf...@ietf.org; Melvin Carvalho
> Oggetto: Re: [webfinger] Possibly speeding up the RFC process
I wouldn't enter the debate of who's represented behind a specific URI. It is up to the domain admin to manage the account namespace. Could you better clarify your issue here?
Re the acct: URI scheme I do support Paul's view that at this stage there is no URI-way of identifying *user accounts* globally. It is already widely used in federated social networks that will become a big consumer of webfinger eventually and could easily reuse these "acct:" URIs in activity streams in the actor/id field (normatively defined as anyURI).
Third, wf was designed for supporting any URI including for example http:, which are not in the form of user@domain. And in general I would recommend that an ietf spec formally define the "resource" parameter as anyURI instead of a free-form string.
walter
> -nick
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.
Melvin Carvalho
Taking your example of http:, how might this work?
Paul E. Jones
> I've been giving this some more thought, if the person running the WF
> service can make up their own system of identifying users (whatever
> works for them), then in order to write a robust WF client, you're going
> to have to do a lot of second guessing. I don't understand why we have
> 'acct:' if (a) it's not required at all, and (b) it's suggested we use
> the full 'us...@example.com' anyway, however (c) we also don't have to
> do that...
(b) The user@domain for will be present with acct:, but not with http: The "resource" being queried is a URI, this we need URI syntax
(c) I don't understand (c)
> In the case of that twitter example. If they wanted to solve this issue,
> they might impose a system like:
>
> /.host-meta/webfinger?resource=jan...@twitter.com
>
> ...that gets the record for the employee Janice
>
> /.host-meta/webfinger?resource=acct:janice
>
> ...that gets the record for the user-account 'janice'
>
> In this case 'acct' prefix referring to just the 'webapp' accounts, and
> not 'admin/employee' accounts.
But I would suggest that no URI prefix (which is not even valid, anyway) is somehow different than "acct:". I would either treat them as equal on the server or reject the plain "user@domain" form that lacks the URI scheme. The client is supposed to ensure requests have a URI scheme.
Now, before you say "I thought you said the 'acct:' scheme was not required." It's not, but that's the recommended scheme for account identifiers. WF provides a response to queries for URIs. Any URI can be used. We just recommend "acct:" for accounts, but "http:" is perfectly valid if requesting information about an HTTP URL.
> I think a clarification of what to use as the resource value to signify
> whether we are, querying an email address (used by, for example, and
> email client, or blog comments). or a user account (used by, for example,
> phpBB, wordpress, twitter, etc.) would be really helpful.
> Otherwise we're going to have similar client complexity to the issues
> we've already discussed regarding using fallback methods. though maybe
> more complicated because we could have false positives if, for example,
> jan...@twitter.com is queried for a user account but the profile for the
> employee is returned.
Paul
Paul E. Jones
Melvin,
Here’s an example:
curl 'https://packetizer.com/.well-known/webfinger?resource=http://www.packetizer.com/'
This does not return much useful information, but I return a user-friendly “Name” for the URI. I could include a URL to a site policy document, have a link relation to a copyright statement, etc.
Paul
Melvin Carvalho
Melvin,
Here’s an example:
curl 'https://packetizer.com/.well-known/webfinger?resource=http://www.packetizer.com/'
This does not return much useful information, but I return a user-friendly “Name” for the URI. I could include a URL to a site policy document, have a link relation to a copyright statement, etc.
I see what you are doing here and it's a neat implementation. I think that if http discovery is in scope of webfinger, then data returned should be consistent with HTTP GET, which is currently the best practice for http discovery, imho. Otherwise there is the potential danger, for things getting out of sync, depending on which discovery method is used.
Does that make sense?
Paul E. Jones
Melvin,
Honestly, I don’t follow exactly what you’re saying. WF allows any URI, this this form is allowed. What the server chooses to include in the response is not specified. The concept here is not new. This was also possible in RFC 6415 (host-meta & LRDD). But, how that relates to “HTTP GET”, I do not know. Are you referring to mark-up in an HTML document? If so, it's impossible to ensure consistency in all cases, since many HTTP resources return non-HTML content. In any case, this is really a subject that should be outside the scope of WF. WF defines how to convey information. We should not get into comparison between “HTTP GET” discovery mechanisms.
Paul
From: Melvin Carvalho [mailto:melvinc...@gmail.com]
Sent: Wednesday, December 19, 2012 8:43 AM
To: Paul E. Jones
Cc: Goix Laurent Walter; webf...@googlegroups.com; webf...@ietf.org
Subject: Re: [webfinger] Possibly speeding up the RFC process
Melvin Carvalho
Melvin,
Honestly, I don’t follow exactly what you’re saying. WF allows any URI, this this form is allowed. What the server chooses to include in the response is not specified. The concept here is not new. This was also possible in RFC 6415 (host-meta & LRDD). But, how that relates to “HTTP GET”, I do not know. Are you referring to mark-up in an HTML document? If so, it's impossible to ensure consistency in all cases, since many HTTP resources return non-HTML content. In any case, this is really a subject that should be outside the scope of WF. WF defines how to convey information. We should not get into comparison between “HTTP GET” discovery mechanisms.
HTTP is not strictly coupled to HTML, HTML is simply one MIME type. GET can return HTML, images, audio, XML, JSON etc. Many of the serializations contain data points either in the header, or in the payload. This year, embedding data in html documents (as well as headers) has achieved REC status and has had significant deployment (25%-50% of the web). As such this is a form of 'follow your nose discovery'. There is a large body of work at the W3C and other places, that have covered HTTP based discovery in great detail, with 100s if man years worth of standardization.
I could be mistaken, but if it is in scope that webfinger includes http, the overlap with existing methods of discovery may be sensible as part of standardization, to ensure compatibility across the whole internet.
Paul E. Jones
Melvin,
OK, I do understand a little better.
WF does allow any URI, but does not go into detail about what information is returned when a client queries using a particular URI scheme as the resource parameter. One could make the argument that “http” ought not be used. One could also make the argument that there should be consistency between what WF returns for an “http” URI and what kind of metadata is returned when simply querying the resource should be consistent.
However, I don’t think that should be included in the WF spec itself. Just as we’re going to be defining link relations, properties, perhaps methods for auto-provisioning, etc., this is a good subject to take up as a follow-on activity or even an activity in the W3C.
Melvin Carvalho
Melvin,
OK, I do understand a little better.
WF does allow any URI, but does not go into detail about what information is returned when a client queries using a particular URI scheme as the resource parameter. One could make the argument that “http” ought not be used. One could also make the argument that there should be consistency between what WF returns for an “http” URI and what kind of metadata is returned when simply querying the resource should be consistent.
However, I don’t think that should be included in the WF spec itself. Just as we’re going to be defining link relations, properties, perhaps methods for auto-provisioning, etc., this is a good subject to take up as a follow-on activity or even an activity in the W3C.
+1
Nick Jennings
I don't want to beat a dead horse, but so far I feel like either I'm
missing something pretty major, or I'm not making myself clear. So
I'll give it another shot:
My concern is that there seems to me to be a BIG ambiguity problem
which could create false positives during lookups, and different
conventions could be made up by sites with emails & web accounts on
the same server, that might require a WF client to use several
different URIs to find a record (and there's not 100% sure way of
knowing they got the right record).
If there is a WF client in a mail-app, it's going to want to query
against the email address. Not a website account. So, IMO there needs
to be a way to specify you are querying for an email address, what
that method is, I don't know, but the ambiguity of 'acct' is
problematic for a client library that knows exactly what it's talking
about (an email address).
/.host-meta/webfinger?resource=mailto:us...@example.com
This would make it clear to the server "I got an *email address* and
would like any record associated with it.
Whereas:
/.host-meta/webfinger?resource=acct:us...@example.com
OR
/.host-meta/webfinger?resource=http://example.com/users/user
Would make it clear that you are querying 'user' from the sites user
accounts. This could be the way of implying "whatever service you
host, I need a record for a user of this name". If the WF server was
an email server, then it could be one in the same as a
mailto:us...@example.com URI and the result would be the same no matter
what. However if it's twitter (for example) or some other web service
with accounts, it would know you mean the account 'user' of that web
service.
My point is that the context is only really going to be known by the
client, and it will have no way of knowing if the result it got was
for the right account because it has no way of being specific. IMO
this is trivial to implement on the server side (by default, mailto
and acct would be one in the same, but you could split the two if you
needed) and would make things easy to clarify by the client when
needed.
-Nick
Paul E. Jones
> I don't want to beat a dead horse, but so far I feel like either I'm
> missing something pretty major, or I'm not making myself clear. So I'll
> give it another shot:
>
> My concern is that there seems to me to be a BIG ambiguity problem which
> could create false positives during lookups, and different conventions
> could be made up by sites with emails & web accounts on the same server,
> that might require a WF client to use several different URIs to find a
> record (and there's not 100% sure way of knowing they got the right
> record).
It goes on to say that mailto is not ideal for user accounts, but would be useful for mail server configuration. If you want to see live examples of the difference, see:
curl https://packetizer.com/.well-known/webfinger?
resource=acct:pau...@packetizer.com
vs.
curl https://packetizer.com/.well-known/webfinger?
resource=mailto:pau...@packetizer.com
The latter provides information about how my email client should provision itself.
> If there is a WF client in a mail-app, it's going to want to query
> against the email address. Not a website account. So, IMO there needs to
> be a way to specify you are querying for an email address, what that
> method is, I don't know, but the ambiguity of 'acct' is problematic for
> a client library that knows exactly what it's talking about (an email
> address).
>
> /.host-meta/webfinger?resource=mailto:us...@example.com
> This would make it clear to the server "I got an *email address* and
> would like any record associated with it.
>
> Whereas:
>
> /.host-meta/webfinger?resource=acct:us...@example.com
>
> OR
>
> /.host-meta/webfinger?resource=http://example.com/users/user
>
> Would make it clear that you are querying 'user' from the sites user
> accounts. This could be the way of implying "whatever service you host,
> I need a record for a user of this name". If the WF server was an email
> server, then it could be one in the same as a mailto:us...@example.com
> URI and the result would be the same no matter what. However if it's
> twitter (for example) or some other web service with accounts, it would
> know you mean the account 'user' of that web service.
For a lot of reasons, I think having different user identifiers at the same domain level is a bad idea and I don't know how people will deal with that. They should not do that, really. People search for people using these identifiers. It's an issue that extends beyond just WF. Call it a part of "good domain hygiene".
> My point is that the context is only really going to be known by the
> client, and it will have no way of knowing if the result it got was for
> the right account because it has no way of being specific. IMO this is
> trivial to implement on the server side (by default, mailto and acct
> would be one in the same, but you could split the two if you
> needed) and would make things easy to clarify by the client when needed.
curl https://packetizer.com/.well-known/webfinger?
resource=xmpp:pau...@packetizer.com
That will return a different set of results. There is only minimal information there, since we have not actually defined the auto-provisioning stuff. Again, this could all be returned as part of a query to acct:, but I personally like the split. It could also be possible that each of these URIs (acct:, mailto:, or xmpp:) are just aliases of each other and, regardless of what the client queries, it gets the same JRD.
What I cannot fix are domains that have two people associated with a given user identifier.
Paul
Nick Jennings
Thanks for your patience Paul :) that cleared things up!
Goix Laurent Walter
Thank you indeed for rewording. My comments inline.
>
> Hi Walter and Paul,
>
> I don't want to beat a dead horse, but so far I feel like either I'm
> missing something pretty major, or I'm not making myself clear. So
> I'll give it another shot:
>
> My concern is that there seems to me to be a BIG ambiguity problem
> which could create false positives during lookups, and different
> conventions could be made up by sites with emails & web accounts on
> the same server, that might require a WF client to use several
> different URIs to find a record (and there's not 100% sure way of
> knowing they got the right record).
>
> If there is a WF client in a mail-app, it's going to want to query
> against the email address. Not a website account. So, IMO there needs
> to be a way to specify you are querying for an email address, what
> that method is, I don't know, but the ambiguity of 'acct' is
> problematic for a client library that knows exactly what it's talking
> about (an email address).
>
> /.host-meta/webfinger?resource=mailto:us...@example.com
>
> This would make it clear to the server "I got an *email address* and
> would like any record associated with it.
> Whereas:
>
> /.host-meta/webfinger?resource=acct:us...@example.com
>
> OR
>
> /.host-meta/webfinger?resource=http://example.com/users/user
>
> Would make it clear that you are querying 'user' from the sites user
> accounts. This could be the way of implying "whatever service you
> host, I need a record for a user of this name".
> If the WF server was
> an email server, then it could be one in the same as a
> mailto:us...@example.com URI and the result would be the same no matter
> what. However if it's twitter (for example) or some other web service
> with accounts, it would know you mean the account 'user' of that web
> service.
>
>
> My point is that the context is only really going to be known by the
> client, and it will have no way of knowing if the result it got was
> for the right account because it has no way of being specific.
> IMO
> this is trivial to implement on the server side (by default, mailto
> and acct would be one in the same, but you could split the two if you
> needed) and would make things easy to clarify by the client when
> needed.
Walter
>
> -Nick
Goix Laurent Walter
Walter
> For a lot of reasons, I think having different user identifiers at the same domain level is a bad idea and I don't know how people will deal with that. They should not do that, really. People search for people using these identifiers. It's an issue that extends beyond just WF. Call it a part of "good domain hygiene".
>
>> My point is that the context is only really going to be known by the
>> client, and it will have no way of knowing if the result it got was for
>> the right account because it has no way of being specific. IMO this is
>> trivial to implement on the server side (by default, mailto and acct
>> would be one in the same, but you could split the two if you
>> needed) and would make things easy to clarify by the client when needed.
>
> It would certainly be legitimate to have acct: and mailto: return the same set of link relations. A client would likely be looking for only certain "rel" values, anyway. However, I personally like to split them, since they serve an entirely different purpose. If my XMPP client was looking for how to configure itself, for example, I would expect it to query like this:
>
> curl https://packetizer.com/.well-known/webfinger?
> resource=xmpp:pau...@packetizer.com
>
> That will return a different set of results. There is only minimal information there, since we have not actually defined the auto-provisioning stuff. Again, this could all be returned as part of a query to acct:, but I personally like the split. It could also be possible that each of these URIs (acct:, mailto:, or xmpp:) are just aliases of each other and, regardless of what the client queries, it gets the same JRD.
>
> What I cannot fix are domains that have two people associated with a given user identifier.
>
> Paul
>
>
Paul E. Jones
> > If I were writing a client and saw an email address
> "pau...@packetizer.com", I would assume the associated account URI is
> acct:pau...@packetizer.com. Personally, I think that is a reasonable
> thing to do.
>
> I would rather expect that natively the email client queries for mailto:
> as this is the real identifier it knows of (the ones used in emails) and
> converting it into acct: is just a best guess. The target server should
> surely knows that mailto: identifier since an email was probably
> received from that id, whilst the corresponding acct: identifier may not
> exist. Does this make sense?
I just added that to my database so you can see what it would look like:
That said, I think a "best guess" is actually pretty reasonable. Consider that the email client actually NEVER gets a "mailto:pau...@packetizer.com" from the SMTP server. Rather, it gets this:
From: "Paul E. Jones" <pau...@packetizer.com>
This is an email address, but I would argue that it should be safe to assume that acct:pau...@packetizer.com will identify the user's account (vs. his email-related configuration information or whatever).
So, as a way forward, we have a couple of options:
1) Allow the assumption to be made that the account for
the above address is "acct:"
2) Don't allow the assumption and require a query to
"mailto" and discover the "acct" URI
Paul
Goix Laurent Walter
My preferred option for the example would be with mailto: (optionally mentioning that the answer could provide a proof of existence of the equivalent acct: uri through an acct rel.
Walter
Paul E. Jones
> > So, as a way forward, we have a couple of options:
> > 1) Allow the assumption to be made that the account for
> > the above address is "acct:"
> > 2) Don't allow the assumption and require a query to
> > "mailto" and discover the "acct" URI
>
> I am not sure we have to standardize that specific behaviour. It would
> be impossible to do for all use cases with a normative language. That
> said it could be clearly mentioned in the examples to guide implementors.
> My preferred option for the example would be with mailto: (optionally
> mentioning that the answer could provide a proof of existence of the
> equivalent acct: uri through an acct rel.
Paul