|
Summarizing my grouse with XRD
This is further to my post "Open Challenge to webfinger, XRD". The post has grown in all directions. So I would like to put my arguments in a nutshell.
The idea of an XRD without a Subject is unacceptable for the following reasons. 1) XRD without <Subject> is a security risk. If nothing, it makes life easier for the "Man in the middle attacker".
2) Cacheing of XRD's is thrown out of the window. You can't cache XRD's without a <Subject>. I firmly believe that Cacheing of XRD's will be a "BIG THING". Applications "IN THE KNOW OF XRD's" will deifinitely like to cache XRD's. It will definitely speed up the discovery process.
3) I am seeing the real possibility that applications will be developed where users can "save" their XRD's locally. Further, users may be able to to upload their XRD's to sites that require it. All this will require a <Subject>.
4) I "SUSPECT" XRD's without <Subject> plays into the interest's of large organizations. XRD"s without <Subject> will keep us dependent on the large organizations. Because XRD"s without <Subject> are transient and cannot be "Saved".
Now if we conclude from the four points above that the <Subject> of the XRD MUST be mandatory. The followimg will follow. 1) Host-meta MUST have a <Subject> Element. 2) The idea that the host-meta XRD must be different from the resource XRD pointed to with the same domain, is a "KLUTZ" being enforced on us by the large organizations, who would like to have XRD's without <Subject>. I have explained my argument against this in answer to John Bradley and John Kemp which I will copy and paste here.
>>>>>>> Now this is exactly the point I am making, that the personal XRD and host meta are the same in the case a domain name also describes a personal resource. In the case of "thread-safe.net" your personal XRD and the host meta are the same. There is no contradiction here. It is only the context in which the resource is looked for that makes a difference.
So if you typed in " thread-safe.net" as your OpenID, the application will simply treat the host meta as your personal XRD. On the other hand if you typed in john@... or thread-safe.net/john, the application will treat the XRD as host meta and look for a URITemplate with Rel="describedby" + MediaType="application/xrd_xml".
The Rel values for your Personal Links and "general" resource Links will not be that same. There will be no overlap or contradictions here. This way we keep the whole concept clean and simple.
<<<<<<
>>>>>>> The application looking for a resource already knows wether it is looking for an "information resource" or "non information resource". The application already knows what it is looking for in an XRD. The idea of trying to differentiate this XRD is moot under the circumstances. Unless of cource you can show a use case where an application does NOT know what it is looking for in an XRD.
<<<<<<<<<
Regarding the fact that I have suggested the idiocy of XRI TC in the earlier thread. I want to make a clarification on this. By no means am I suggesting that members of the XRI TC individually are idiots. On the other hand I consider them "brilliant individuals" alone. Unfortunately the way the world works, brilliant individuals can collectively come up with "IDIOTIC" conclusions. And this is not only true of the XRI TC but any group of people coming together worldwide. The phrase "The Camel is a Horse designed by a committee" is very appropriate here.
I have a third grouse with XRD about "delegation". But I will leave it for another post.
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Summarizing my grouse with XRD
On Wed, Oct 21, 2009 at 8:47 AM, Santosh Rajan < santrajan@...> wrote:
> This is further to my post "Open Challenge to webfinger, XRD". The post has
> grown in all directions. So I would like to put my arguments in a nutshell.
>
> The idea of an XRD without a Subject is unacceptable for the following
> reasons.
> 1) XRD without <Subject> is a security risk. If nothing, it makes life
> easier for the "Man in the middle attacker".
Not necessarily all applications are security sensitive. Think about
robots.txt. Does it have a Subject? No. Does it introduce security
vulnerabilities? No. Is it metadata about something? Yes.
> 2) Cacheing of XRD's is thrown out of the window. You can't cache XRD's
> without a <Subject>. I firmly believe that Cacheing of XRD's will be a "BIG
> THING". Applications "IN THE KNOW OF XRD's" will deifinitely like to cache
> XRD's. It will definitely speed up the discovery process.
No. Lack of a subject does not prevent anyone from caching robots.txt
and will not prevent anyone from caching XRDs. Indeed, caching XRD
works completely independent of the Subject. For instance, if a
client follows a sequence of cacheable redirects and gets an XRD
document, it should be able to retrieve the XRD from cache next time
it discovers the same resource (regardless of whether the resource is
also the Subject of the XRD, an Alias listed in the XRD or if the XRD
has no Subject).
> 3) I am seeing the real possibility that applications will be developed
> where users can "save" their XRD's locally. Further, users may be able to to
> upload their XRD's to sites that require it. All this will require a
> <Subject>.
No, it doesn't. See robots.txt
--
--Breno
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Summarizing my grouse with XRD
Comparing robots.txt with an XRD is like comparing "apples with oranges". Can you do better than that? Cacheing robots.txt is not the same as cacheing an XRD. I will explain. If my browser wants to cache all my XRD's. This is a real possibility. I may have XRD's at Google, Yahoo, Microsoft and "my own" host. The only way you can differentiate between all these XRD's is if the XRD;'s have a <Subject>.
On Wed, Oct 21, 2009 at 9:28 PM, Breno de Medeiros <breno@...> wrote:
On Wed, Oct 21, 2009 at 8:47 AM, Santosh Rajan < santrajan@...> wrote:
> This is further to my post "Open Challenge to webfinger, XRD". The post has
> grown in all directions. So I would like to put my arguments in a nutshell.
>
> The idea of an XRD without a Subject is unacceptable for the following
> reasons.
> 1) XRD without <Subject> is a security risk. If nothing, it makes life
> easier for the "Man in the middle attacker".
robots.txt. Does it have a Subject? No. Does it introduce security
vulnerabilities? No. Is it metadata about something? Yes.
> 2) Cacheing of XRD's is thrown out of the window. You can't cache XRD's
> without a <Subject>. I firmly believe that Cacheing of XRD's will be a "BIG
> THING". Applications "IN THE KNOW OF XRD's" will deifinitely like to cache
> XRD's. It will definitely speed up the discovery process.
No. Lack of a subject does not prevent anyone from caching robots.txt
and will not prevent anyone from caching XRDs. Indeed, caching XRD
works completely independent of the Subject. For instance, if a
client follows a sequence of cacheable redirects and gets an XRD
document, it should be able to retrieve the XRD from cache next time
it discovers the same resource (regardless of whether the resource is
also the Subject of the XRD, an Alias listed in the XRD or if the XRD
has no Subject).
> 3) I am seeing the real possibility that applications will be developed
> where users can "save" their XRD's locally. Further, users may be able to to
> upload their XRD's to sites that require it. All this will require a
> <Subject>.
No, it doesn't. See robots.txt
--
--Breno
-- http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Summarizing my grouse with XRD
No, there are no differences. Caching by the Subject is the wrong
thing. If you are starting the discovery from a resource different
from the Subject, then caching by the Subject will not actually save
you network fetches. Anyway, that is not how HTTP caching works,
caching is based on where you got the resource from, not on some clue
embedded in the document.
Basically, for this to work with existing cache infrastructure, cache
should work at the HTTP layer, and validation or trust reasoning be
performed at a higher (XRD-knowledgeable) level.
On Wed, Oct 21, 2009 at 9:07 AM, Santosh Rajan < santrajan@...> wrote:
> Comparing robots.txt with an XRD is like comparing "apples with oranges".
> Can you do better than that? Cacheing robots.txt is not the same as cacheing
> an XRD. I will explain.
> If my browser wants to cache all my XRD's. This is a real possibility. I may
> have XRD's at Google, Yahoo, Microsoft and "my own" host. The only way you
> can differentiate between all these XRD's is if the XRD;'s have a <Subject>.
>
--
--Breno
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Summarizing my grouse with XRD
When I spoke about cacheing in point no (2) I clearly mentioned 'Applications "IN THE KNOW OF XRD's"'. So I am talking cacheing about of XRD's by applications who are aware of XRD's, which is more than the general cacheing of XRD's, like any other file you are talking about. And if i am still not clear to you, what I am suggesting is that XRD's will be used as something like hcard's, and they will cache'd in that context.
On Wed, Oct 21, 2009 at 9:45 PM, Breno de Medeiros <breno@...> wrote:
No, there are no differences. Caching by the Subject is the wrong
thing. If you are starting the discovery from a resource different
from the Subject, then caching by the Subject will not actually save
you network fetches. Anyway, that is not how HTTP caching works,
caching is based on where you got the resource from, not on some clue
embedded in the document.
Basically, for this to work with existing cache infrastructure, cache
should work at the HTTP layer, and validation or trust reasoning be
performed at a higher (XRD-knowledgeable) level.
On Wed, Oct 21, 2009 at 9:07 AM, Santosh Rajan < santrajan@...> wrote:
> Comparing robots.txt with an XRD is like comparing "apples with oranges".
> Can you do better than that? Cacheing robots.txt is not the same as cacheing
> an XRD. I will explain.
> If my browser wants to cache all my XRD's. This is a real possibility. I may
> have XRD's at Google, Yahoo, Microsoft and "my own" host. The only way you
> can differentiate between all these XRD's is if the XRD;'s have a <Subject>.
>
--Breno
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
-- http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
 Re: Summarizing my grouse with XRD
You said that you will have to cache with a virtual subject. And that is my concern. So the onus is on a second or third party to provide a <Subject> for the XRD. You will agree with me that it doesn't beat the first party providing the <Subject>.
On Wed, Oct 21, 2009 at 9:54 PM, Breno de Medeiros <breno@...> wrote:
That requires you to build your own caching approach, which is fine,
but actually gives you few benefits. If you use HTTP for caching, it
will be cached in every proxy in the internet in additional to the
client, so the benefits are exponentially higher.
On the other hand, there is nothing preventing you from creating your
own cache. If a Subject is missing you cache with a virtual Subject
based on where you started the discovery process at.
On Wed, Oct 21, 2009 at 9:22 AM, Santosh Rajan < santrajan@...> wrote:
> When I spoke about cacheing in point no (2) I clearly mentioned
> 'Applications "IN THE KNOW OF XRD's"'. So I am talking cacheing about of
> XRD's by applications who are aware of XRD's, which is more than the general
> cacheing of XRD's, like any other file you are talking about. And if i am
> still not clear to you, what I am suggesting is that XRD's will be used as
> something like hcard's, and they will cache'd in that context.
>
>
--Breno
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
-- http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Summarizing my grouse with XRD
Considering the following use case: the same XRD, stored at the same
location, is used by a large number of URLs. The developers can't
include 1000's of Aliases in the document. If this is not security
sensitive, they can simply create an XRD without Subject.
The current model for XRD would allow it to be used this way, and
caching would just work. Adding a Subject would break both caching and
likely preventing this to work at all.
--
--Breno
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Summarizing my grouse with XRD
On Wed, Oct 21, 2009 at 5:07 PM, Santosh Rajan < santrajan@...> wrote:
> Comparing robots.txt with an XRD is like comparing "apples with oranges".
> Can you do better than that? Cacheing robots.txt is not the same as cacheing
> an XRD. I will explain.
> If my browser wants to cache all my XRD's. This is a real possibility. I may
> have XRD's at Google, Yahoo, Microsoft and "my own" host. The only way you
> can differentiate between all these XRD's is if the XRD;'s have a <Subject>.
If we were defining robots.txt today, we might consider doing it as an
XRD. So, it seems to me that the comparison is entirely fair.
>
> On Wed, Oct 21, 2009 at 9:28 PM, Breno de Medeiros < breno@...> wrote:
>>
>> On Wed, Oct 21, 2009 at 8:47 AM, Santosh Rajan < santrajan@...>
>> wrote:
>> > This is further to my post "Open Challenge to webfinger, XRD". The post
>> > has
>> > grown in all directions. So I would like to put my arguments in a
>> > nutshell.
>> >
>> > The idea of an XRD without a Subject is unacceptable for the following
>> > reasons.
>> > 1) XRD without <Subject> is a security risk. If nothing, it makes life
>> > easier for the "Man in the middle attacker".
>>
>> Not necessarily all applications are security sensitive. Think about
>> robots.txt. Does it have a Subject? No. Does it introduce security
>> vulnerabilities? No. Is it metadata about something? Yes.
>>
>> > 2) Cacheing of XRD's is thrown out of the window. You can't cache XRD's
>> > without a <Subject>. I firmly believe that Cacheing of XRD's will be a
>> > "BIG
>> > THING". Applications "IN THE KNOW OF XRD's" will deifinitely like to
>> > cache
>> > XRD's. It will definitely speed up the discovery process.
>>
>> No. Lack of a subject does not prevent anyone from caching robots.txt
>> and will not prevent anyone from caching XRDs. Indeed, caching XRD
>> works completely independent of the Subject. For instance, if a
>> client follows a sequence of cacheable redirects and gets an XRD
>> document, it should be able to retrieve the XRD from cache next time
>> it discovers the same resource (regardless of whether the resource is
>> also the Subject of the XRD, an Alias listed in the XRD or if the XRD
>> has no Subject).
>>
>> > 3) I am seeing the real possibility that applications will be developed
>> > where users can "save" their XRD's locally. Further, users may be able
>> > to to
>> > upload their XRD's to sites that require it. All this will require a
>> > <Subject>.
>>
>> No, it doesn't. See robots.txt
>>
>>
>>
>> --
>> --Breno
>
>
>
> --
> http://hi.im/santosh>
>
>
> _______________________________________________
> general mailing list
> general@...
> http://lists.openid.net/mailman/listinfo/openid-general>
>
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Summarizing my grouse with XRD
The same XRD with a unique <Subject> is independant of the "large number of URL's" that is presumably pointing to it. If you are talking about delegation I don't know how this relates to cacheing. Can you give a real world example?
On Wed, Oct 21, 2009 at 10:12 PM, Breno de Medeiros <breno@...> wrote:
Considering the following use case: the same XRD, stored at the same
location, is used by a large number of URLs. The developers can't
include 1000's of Aliases in the document. If this is not security
sensitive, they can simply create an XRD without Subject.
The current model for XRD would allow it to be used this way, and
caching would just work. Adding a Subject would break both caching and
likely preventing this to work at all.
--
--Breno
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
-- http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Summarizing my grouse with XRD
Robots.txt's are unique to a specific resource. The scope of XRD's is larger than that. XRD's are not unique to individuals when used as indentities. Using a <Subject> is the only way you can differentiate XRD's belonging to the same individual or resource. Thats why i said we are comparing apples and oranges.
On Wed, Oct 21, 2009 at 10:24 PM, Ben Laurie <benl@...> wrote:
On Wed, Oct 21, 2009 at 5:07 PM, Santosh Rajan < santrajan@...> wrote:
> Comparing robots.txt with an XRD is like comparing "apples with oranges".
> Can you do better than that? Cacheing robots.txt is not the same as cacheing
> an XRD. I will explain.
> If my browser wants to cache all my XRD's. This is a real possibility. I may
> have XRD's at Google, Yahoo, Microsoft and "my own" host. The only way you
> can differentiate between all these XRD's is if the XRD;'s have a <Subject>.
XRD. So, it seems to me that the comparison is entirely fair.
>
> On Wed, Oct 21, 2009 at 9:28 PM, Breno de Medeiros < breno@...> wrote:
>>
>> On Wed, Oct 21, 2009 at 8:47 AM, Santosh Rajan < santrajan@...>
>> wrote:
>> > This is further to my post "Open Challenge to webfinger, XRD". The post
>> > has
>> > grown in all directions. So I would like to put my arguments in a
>> > nutshell.
>> >
>> > The idea of an XRD without a Subject is unacceptable for the following
>> > reasons.
>> > 1) XRD without <Subject> is a security risk. If nothing, it makes life
>> > easier for the "Man in the middle attacker".
>>
>> Not necessarily all applications are security sensitive. Think about
>> robots.txt. Does it have a Subject? No. Does it introduce security
>> vulnerabilities? No. Is it metadata about something? Yes.
>>
>> > 2) Cacheing of XRD's is thrown out of the window. You can't cache XRD's
>> > without a <Subject>. I firmly believe that Cacheing of XRD's will be a
>> > "BIG
>> > THING". Applications "IN THE KNOW OF XRD's" will deifinitely like to
>> > cache
>> > XRD's. It will definitely speed up the discovery process.
>>
>> No. Lack of a subject does not prevent anyone from caching robots.txt
>> and will not prevent anyone from caching XRDs. Indeed, caching XRD
>> works completely independent of the Subject. For instance, if a
>> client follows a sequence of cacheable redirects and gets an XRD
>> document, it should be able to retrieve the XRD from cache next time
>> it discovers the same resource (regardless of whether the resource is
>> also the Subject of the XRD, an Alias listed in the XRD or if the XRD
>> has no Subject).
>>
>> > 3) I am seeing the real possibility that applications will be developed
>> > where users can "save" their XRD's locally. Further, users may be able
>> > to to
>> > upload their XRD's to sites that require it. All this will require a
>> > <Subject>.
>>
>> No, it doesn't. See robots.txt
>>
>>
>>
>> --
>> --Breno
>
>
>
> --
> http://hi.im/santosh
>
>
>
> general mailing list
> general@...
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
-- http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Summarizing my grouse with XRD
Yes a XRD can be used for identity. In that case it should be a signed XRD (with Subject)
However a XRD can be used to describe any resource (URI).
I may have a XRD that describes my site in the same way a robots.txt might.
It might be used to enable Identity in the browser by allowing browser plugins to discover the sites policy (see Flock and other IdIB projects)
It may be more practical for some sites to point to a single document that is authoritative for all of the URI on there site rather than forcing them to create individual XRD for each URI where it may not be necessary.
XRD supports both models. I know you want us to restrict implementers to a single model.
That is not the role of the XRI-TC if we don't support the use case people will crate there own hacks to get around the limitation.
I would oppose any vote in the TC to always require a Subject element in the XSD.
John B.
On 2009-10-21, at 2:37 PM, Santosh Rajan wrote: Robots.txt's are unique to a specific resource. The scope of XRD's is larger than that. XRD's are not unique to individuals when used as indentities. Using a <Subject> is the only way you can differentiate XRD's belonging to the same individual or resource. Thats why i said we are comparing apples and oranges.
On Wed, Oct 21, 2009 at 10:24 PM, Ben Laurie <benl@...> wrote:
On Wed, Oct 21, 2009 at 5:07 PM, Santosh Rajan < santrajan@...> wrote:
> Comparing robots.txt with an XRD is like comparing "apples with oranges".
> Can you do better than that? Cacheing robots.txt is not the same as cacheing
> an XRD. I will explain.
> If my browser wants to cache all my XRD's. This is a real possibility. I may
> have XRD's at Google, Yahoo, Microsoft and "my own" host. The only way you
> can differentiate between all these XRD's is if the XRD;'s have a <Subject>.
XRD. So, it seems to me that the comparison is entirely fair.
>
> On Wed, Oct 21, 2009 at 9:28 PM, Breno de Medeiros < breno@...> wrote:
>>
>> On Wed, Oct 21, 2009 at 8:47 AM, Santosh Rajan < santrajan@...>
>> wrote:
>> > This is further to my post "Open Challenge to webfinger, XRD". The post
>> > has
>> > grown in all directions. So I would like to put my arguments in a
>> > nutshell.
>> >
>> > The idea of an XRD without a Subject is unacceptable for the following
>> > reasons.
>> > 1) XRD without <Subject> is a security risk. If nothing, it makes life
>> > easier for the "Man in the middle attacker".
>>
>> Not necessarily all applications are security sensitive. Think about
>> robots.txt. Does it have a Subject? No. Does it introduce security
>> vulnerabilities? No. Is it metadata about something? Yes.
>>
>> > 2) Cacheing of XRD's is thrown out of the window. You can't cache XRD's
>> > without a <Subject>. I firmly believe that Cacheing of XRD's will be a
>> > "BIG
>> > THING". Applications "IN THE KNOW OF XRD's" will deifinitely like to
>> > cache
>> > XRD's. It will definitely speed up the discovery process.
>>
>> No. Lack of a subject does not prevent anyone from caching robots.txt
>> and will not prevent anyone from caching XRDs. Indeed, caching XRD
>> works completely independent of the Subject. For instance, if a
>> client follows a sequence of cacheable redirects and gets an XRD
>> document, it should be able to retrieve the XRD from cache next time
>> it discovers the same resource (regardless of whether the resource is
>> also the Subject of the XRD, an Alias listed in the XRD or if the XRD
>> has no Subject).
>>
>> > 3) I am seeing the real possibility that applications will be developed
>> > where users can "save" their XRD's locally. Further, users may be able
>> > to to
>> > upload their XRD's to sites that require it. All this will require a
>> > <Subject>.
>>
>> No, it doesn't. See robots.txt
>>
>>
>>
>> --
>> --Breno
>
>
>
> --
> http://hi.im/santosh
>
>
>
> general mailing list
> general@...
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
-- http://hi.im/santosh
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Summarizing my grouse with XRD
John Bradley wrote:
> Yes a XRD can be used for identity. In that case it should be a signed
> XRD (with Subject)
>
> However a XRD can be used to describe any resource (URI).
What does it mean then (in XRD terms) if an XRD doesn't identify the
resource it describes (ie. it doesn't have a subject)?
- johnk
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Summarizing my grouse with XRD
XRD's used as identity, signed with a subject is a GOOD thing. However if you allow XRD's without subject, companies mayl choose to use unsigned XRD's as identity, without subject, and use transport layer security, which is a BAD thing.
On Wed, Oct 21, 2009 at 11:18 PM, John Bradley <ve7jtb@...> wrote:
Yes a XRD can be used for identity. In that case it should be a signed XRD (with Subject)
However a XRD can be used to describe any resource (URI).
I may have a XRD that describes my site in the same way a robots.txt might.
It might be used to enable Identity in the browser by allowing browser plugins to discover the sites policy (see Flock and other IdIB projects)
It may be more practical for some sites to point to a single document that is authoritative for all of the URI on there site rather than forcing them to create individual XRD for each URI where it may not be necessary.
XRD supports both models. I know you want us to restrict implementers to a single model.
That is not the role of the XRI-TC if we don't support the use case people will crate there own hacks to get around the limitation.
I would oppose any vote in the TC to always require a Subject element in the XSD.
John B.
On 2009-10-21, at 2:37 PM, Santosh Rajan wrote:
Robots.txt's are unique to a specific resource. The scope of XRD's is larger than that. XRD's are not unique to individuals when used as indentities. Using a <Subject> is the only way you can differentiate XRD's belonging to the same individual or resource. Thats why i said we are comparing apples and oranges.
On Wed, Oct 21, 2009 at 10:24 PM, Ben Laurie <benl@...> wrote:
On Wed, Oct 21, 2009 at 5:07 PM, Santosh Rajan < santrajan@...> wrote:
> Comparing robots.txt with an XRD is like comparing "apples with oranges".
> Can you do better than that? Cacheing robots.txt is not the same as cacheing
> an XRD. I will explain.
> If my browser wants to cache all my XRD's. This is a real possibility. I may
> have XRD's at Google, Yahoo, Microsoft and "my own" host. The only way you
> can differentiate between all these XRD's is if the XRD;'s have a <Subject>.
XRD. So, it seems to me that the comparison is entirely fair.
>
> On Wed, Oct 21, 2009 at 9:28 PM, Breno de Medeiros < breno@...> wrote:
>>
>> On Wed, Oct 21, 2009 at 8:47 AM, Santosh Rajan < santrajan@...>
>> wrote:
>> > This is further to my post "Open Challenge to webfinger, XRD". The post
>> > has
>> > grown in all directions. So I would like to put my arguments in a
>> > nutshell.
>> >
>> > The idea of an XRD without a Subject is unacceptable for the following
>> > reasons.
>> > 1) XRD without <Subject> is a security risk. If nothing, it makes life
>> > easier for the "Man in the middle attacker".
>>
>> Not necessarily all applications are security sensitive. Think about
>> robots.txt. Does it have a Subject? No. Does it introduce security
>> vulnerabilities? No. Is it metadata about something? Yes.
>>
>> > 2) Cacheing of XRD's is thrown out of the window. You can't cache XRD's
>> > without a <Subject>. I firmly believe that Cacheing of XRD's will be a
>> > "BIG
>> > THING". Applications "IN THE KNOW OF XRD's" will deifinitely like to
>> > cache
>> > XRD's. It will definitely speed up the discovery process.
>>
>> No. Lack of a subject does not prevent anyone from caching robots.txt
>> and will not prevent anyone from caching XRDs. Indeed, caching XRD
>> works completely independent of the Subject. For instance, if a
>> client follows a sequence of cacheable redirects and gets an XRD
>> document, it should be able to retrieve the XRD from cache next time
>> it discovers the same resource (regardless of whether the resource is
>> also the Subject of the XRD, an Alias listed in the XRD or if the XRD
>> has no Subject).
>>
>> > 3) I am seeing the real possibility that applications will be developed
>> > where users can "save" their XRD's locally. Further, users may be able
>> > to to
>> > upload their XRD's to sites that require it. All this will require a
>> > <Subject>.
>>
>> No, it doesn't. See robots.txt
>>
>>
>>
>> --
>> --Breno
>
>
>
> --
> http://hi.im/santosh
>
>
>
> general mailing list
> general@...
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
-- http://hi.im/santosh
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
-- http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Summarizing my grouse with XRD
It means that some protocol that is using XRD is defining the subject
via some external mechanism.
In the HTTP protocol case there may be an implicit subject based on
the identifier that is being resolved.
All normal http caching would apply in the http: case.
In the IMI/SAML case we have discussed pushing a XRD as a assertion/
claim.
In that case the subject may be the same as the saml:NameID in the
containing saml:Assertion.
It could perhaps be argued that putting a xrd:Subject and signature
inside a signed saml:Asertion is un-neccicary.
Suffice to say it is up to the protocol using XRD to decide what to
make of a XRD without a xrd:Subject.
John B.
On 2009-10-21, at 3:09 PM, John Kemp wrote:
> John Bradley wrote:
>> Yes a XRD can be used for identity. In that case it should be a
>> signed XRD (with Subject)
>> However a XRD can be used to describe any resource (URI).
>
> What does it mean then (in XRD terms) if an XRD doesn't identify the
> resource it describes (ie. it doesn't have a subject)?
>
> - johnk
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Summarizing my grouse with XRD
John Bradley wrote:
> It means that some protocol that is using XRD is defining the subject
> via some external mechanism.
So the XRD spec. is a template spec. meant to be simply incorporated by
reference into other specs. I guess?
>
> In the HTTP protocol case there may be an implicit subject based on the
> identifier that is being resolved.
As mentioned earlier, if the _subject_ of the XRD is identified
(implicitly) by the same URI used to retrieve the XRD itself, then that
seems rather circular.
>
> All normal http caching would apply in the http: case.
Sure, I'm not quibbling with caching...
>
> In the IMI/SAML case we have discussed pushing a XRD as a assertion/claim.
>
> In that case the subject may be the same as the saml:NameID in the
> containing saml:Assertion.
>
> It could perhaps be argued that putting a xrd:Subject and signature
> inside a signed saml:Asertion is un-neccicary.
>
> Suffice to say it is up to the protocol using XRD to decide what to make
> of a XRD without a xrd:Subject.
OK, I think I've understood ;)
Cheers,
- johnk
>
> John B.
>
> On 2009-10-21, at 3:09 PM, John Kemp wrote:
>
>> John Bradley wrote:
>>> Yes a XRD can be used for identity. In that case it should be a
>>> signed XRD (with Subject)
>>> However a XRD can be used to describe any resource (URI).
>>
>> What does it mean then (in XRD terms) if an XRD doesn't identify the
>> resource it describes (ie. it doesn't have a subject)?
>>
>> - johnk
>
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Summarizing my grouse with XRD
XRD is a XML document spec.
On 2009-10-21, at 5:21 PM, John Kemp wrote:
> John Bradley wrote:
>> It means that some protocol that is using XRD is defining the
>> subject via some external mechanism.
>
> So the XRD spec. is a template spec. meant to be simply incorporated
> by reference into other specs. I guess?
>
Like other XML specs eg SAML 2.0 it can be used multiple
specifications that process XML documents.
External specs can profile the XRD spec.
>> In the HTTP protocol case there may be an implicit subject based on
>> the identifier that is being resolved.
>
> As mentioned earlier, if the _subject_ of the XRD is identified
> (implicitly) by the same URI used to retrieve the XRD itself, then
> that seems rather circular.
>
The XML document describes a resource and provides links to associated
resources.
A HTML page doesn't need to explicitly say what URI it is retrieved
from in its internal markup.
Like with HTML sometimes the subject is defined by the transport or
other external method.
Thanks
John B.
>> All normal http caching would apply in the http: case.
>
> Sure, I'm not quibbling with caching...
>
>> In the IMI/SAML case we have discussed pushing a XRD as a assertion/
>> claim.
>> In that case the subject may be the same as the saml:NameID in the
>> containing saml:Assertion.
>> It could perhaps be argued that putting a xrd:Subject and signature
>> inside a signed saml:Asertion is un-neccicary.
>> Suffice to say it is up to the protocol using XRD to decide what to
>> make of a XRD without a xrd:Subject.
>
> OK, I think I've understood ;)
>
> Cheers,
>
> - johnk
>
>> John B.
>> On 2009-10-21, at 3:09 PM, John Kemp wrote:
>>> John Bradley wrote:
>>>> Yes a XRD can be used for identity. In that case it should be a
>>>> signed XRD (with Subject)
>>>> However a XRD can be used to describe any resource (URI).
>>>
>>> What does it mean then (in XRD terms) if an XRD doesn't identify
>>> the resource it describes (ie. it doesn't have a subject)?
>>>
>>> - johnk
>
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Summarizing my grouse with XRD
In other words now you are saying that XRD is another markup language like HTML and SAML. In which case you should be calling it "XRML" for Extensible Resource Markup Language.
So what started as a "Descriptor" has morphed into a "Markup Language".
So this gives scope for someone else to write the "REAL" Extensible Resource Descriptor Specification on top of XRML.
On Thu, Oct 22, 2009 at 2:24 AM, John Bradley <ve7jtb@...> wrote:
XRD is a XML document spec.
On 2009-10-21, at 5:21 PM, John Kemp wrote:
John Bradley wrote:
It means that some protocol that is using XRD is defining the subject via some external mechanism.
So the XRD spec. is a template spec. meant to be simply incorporated by reference into other specs. I guess?
External specs can profile the XRD spec.
In the HTTP protocol case there may be an implicit subject based on the identifier that is being resolved.
As mentioned earlier, if the _subject_ of the XRD is identified (implicitly) by the same URI used to retrieve the XRD itself, then that seems rather circular.
The XML document describes a resource and provides links to associated resources.
A HTML page doesn't need to explicitly say what URI it is retrieved from in its internal markup.
Like with HTML sometimes the subject is defined by the transport or other external method.
Thanks
John B.
All normal http caching would apply in the http: case.
Sure, I'm not quibbling with caching...
In the IMI/SAML case we have discussed pushing a XRD as a assertion/claim.
In that case the subject may be the same as the saml:NameID in the containing saml:Assertion.
It could perhaps be argued that putting a xrd:Subject and signature inside a signed saml:Asertion is un-neccicary.
Suffice to say it is up to the protocol using XRD to decide what to make of a XRD without a xrd:Subject.
OK, I think I've understood ;)
Cheers,
- johnk
John B.
On 2009-10-21, at 3:09 PM, John Kemp wrote:
John Bradley wrote:
Yes a XRD can be used for identity. In that case it should be a signed XRD (with Subject)
However a XRD can be used to describe any resource (URI).
What does it mean then (in XRD terms) if an XRD doesn't identify the resource it describes (ie. it doesn't have a subject)?
- johnk
-- http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Summarizing my grouse with XRD
I suppose if we were starting fresh we could have called it RDML.
I don't know that there is a meaningful distinction between a document format like OpenDocument and meta-markup language like SAML. Technically they are the same.
The XRI-TC will also be producing a XRI 3.0 spec that will use this updated XRD document specification.
Webfinger and others may also produce processing specifications for XRD or profiles of XRD.
XRD is NOT an identifier.
XRDS as currently used in openID discovery stands for eXtesable Resource Descriptor Sequence.
Yadis never made any use of the Sequence feature so we made it optional.
Hense the main document format spec is now called XRD and not XRDS.
I know people are planning on using it with a multitude of different identifiers including email addresses.
It is still XML and the document is a meta-data descriptor not an identifier.
John B.
On 2009-10-21, at 11:13 PM, Santosh Rajan wrote: In other words now you are saying that XRD is another markup language like HTML and SAML. In which case you should be calling it "XRML" for Extensible Resource Markup Language.
So what started as a "Descriptor" has morphed into a "Markup Language".
So this gives scope for someone else to write the "REAL" Extensible Resource Descriptor Specification on top of XRML.
On Thu, Oct 22, 2009 at 2:24 AM, John Bradley <ve7jtb@...> wrote:
XRD is a XML document spec.
On 2009-10-21, at 5:21 PM, John Kemp wrote:
John Bradley wrote:
It means that some protocol that is using XRD is defining the subject via some external mechanism.
So the XRD spec. is a template spec. meant to be simply incorporated by reference into other specs. I guess?
External specs can profile the XRD spec.
In the HTTP protocol case there may be an implicit subject based on the identifier that is being resolved.
As mentioned earlier, if the _subject_ of the XRD is identified (implicitly) by the same URI used to retrieve the XRD itself, then that seems rather circular.
The XML document describes a resource and provides links to associated resources.
A HTML page doesn't need to explicitly say what URI it is retrieved from in its internal markup.
Like with HTML sometimes the subject is defined by the transport or other external method.
Thanks
John B.
All normal http caching would apply in the http: case.
Sure, I'm not quibbling with caching...
In the IMI/SAML case we have discussed pushing a XRD as a assertion/claim.
In that case the subject may be the same as the saml:NameID in the containing saml:Assertion.
It could perhaps be argued that putting a xrd:Subject and signature inside a signed saml:Asertion is un-neccicary.
Suffice to say it is up to the protocol using XRD to decide what to make of a XRD without a xrd:Subject.
OK, I think I've understood ;)
Cheers,
- johnk
John B.
On 2009-10-21, at 3:09 PM, John Kemp wrote:
John Bradley wrote:
Yes a XRD can be used for identity. In that case it should be a signed XRD (with Subject)
However a XRD can be used to describe any resource (URI).
What does it mean then (in XRD terms) if an XRD doesn't identify the resource it describes (ie. it doesn't have a subject)?
- johnk
-- http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Summarizing my grouse with XRD
So it is now clear to me that identity protocols cannot use the XRD specification "as is". There has to be a new "Identity Resource Descriptor" specification sitting in between XRD and all identity protocols that draw from XRD.
I will explain the problem with an hypothetical example. Lets say webfinger were to specify that the <Subject> of the XRD is not required. And a future OpenID spec mandates the use of <Subject>, because the OpenID folks felt that XRD with no Subject was a security risk. The future OpenID Spec will not be able to use the webfinger protocol (which according to current thinking it may want to).
In any case an "Identity Resource Descriptor", without a Subject to describe it, is entirely meaningless to me. So a new identity Layer for XRD is called for that mandates the use of <Subject> in all Identity Resource Descriptors. (IRD's).
On Thu, Oct 22, 2009 at 8:46 AM, John Bradley <ve7jtb@...> wrote:
I suppose if we were starting fresh we could have called it RDML.
I don't know that there is a meaningful distinction between a document format like OpenDocument and meta-markup language like SAML. Technically they are the same.
The XRI-TC will also be producing a XRI 3.0 spec that will use this updated XRD document specification.
Webfinger and others may also produce processing specifications for XRD or profiles of XRD.
XRD is NOT an identifier.
XRDS as currently used in openID discovery stands for eXtesable Resource Descriptor Sequence.
Yadis never made any use of the Sequence feature so we made it optional.
Hense the main document format spec is now called XRD and not XRDS.
I know people are planning on using it with a multitude of different identifiers including email addresses.
It is still XML and the document is a meta-data descriptor not an identifier.
John B.
On 2009-10-21, at 11:13 PM, Santosh Rajan wrote:
In other words now you are saying that XRD is another markup language like HTML and SAML. In which case you should be calling it "XRML" for Extensible Resource Markup Language.
So what started as a "Descriptor" has morphed into a "Markup Language".
So this gives scope for someone else to write the "REAL" Extensible Resource Descriptor Specification on top of XRML.
On Thu, Oct 22, 2009 at 2:24 AM, John Bradley <ve7jtb@...> wrote:
XRD is a XML document spec.
On 2009-10-21, at 5:21 PM, John Kemp wrote:
John Bradley wrote:
It means that some protocol that is using XRD is defining the subject via some external mechanism.
So the XRD spec. is a template spec. meant to be simply incorporated by reference into other specs. I guess?
External specs can profile the XRD spec.
In the HTTP protocol case there may be an implicit subject based on the identifier that is being resolved.
As mentioned earlier, if the _subject_ of the XRD is identified (implicitly) by the same URI used to retrieve the XRD itself, then that seems rather circular.
The XML document describes a resource and provides links to associated resources.
A HTML page doesn't need to explicitly say what URI it is retrieved from in its internal markup.
Like with HTML sometimes the subject is defined by the transport or other external method.
Thanks
John B.
All normal http caching would apply in the http: case.
Sure, I'm not quibbling with caching...
In the IMI/SAML case we have discussed pushing a XRD as a assertion/claim.
In that case the subject may be the same as the saml:NameID in the containing saml:Assertion.
It could perhaps be argued that putting a xrd:Subject and signature inside a signed saml:Asertion is un-neccicary.
Suffice to say it is up to the protocol using XRD to decide what to make of a XRD without a xrd:Subject.
OK, I think I've understood ;)
Cheers,
- johnk
John B.
On 2009-10-21, at 3:09 PM, John Kemp wrote:
John Bradley wrote:
Yes a XRD can be used for identity. In that case it should be a signed XRD (with Subject)
However a XRD can be used to describe any resource (URI).
What does it mean then (in XRD terms) if an XRD doesn't identify the resource it describes (ie. it doesn't have a subject)?
- johnk
-- http://hi.im/santosh
-- http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Summarizing my grouse with XRD
Santosh, IMHO it's not worth all this worry about Subject being optional or not. If 99% of XRDs need Subject because some protocol that will use the XRD requires a Subject, then only 1% of XRDs will not have a Subject,
And those 1% will probably be for very clear edge cases uses of XRD for a specific job that doesn't care whether the XRD has a Subject. All the XRI TC did was recognize that XRD would be useful in that last 1%.
Any protocol that uses XRD for discovery, such as OpenID, is free to specify that Subject is mandatory. If so, anyone who tries to use an XRD without a Subject for OpenID discovery will find it won't work, and will need to add the Subject.
Done (as is, I hope, this thread). =Drummond On Wed, Oct 21, 2009 at 8:42 PM, Santosh Rajan <santrajan@...> wrote:
So it is now clear to me that identity protocols cannot use the XRD specification "as is". There has to be a new "Identity Resource Descriptor" specification sitting in between XRD and all identity protocols that draw from XRD.
I will explain the problem with an hypothetical example. Lets say webfinger were to specify that the <Subject> of the XRD is not required. And a future OpenID spec mandates the use of <Subject>, because the OpenID folks felt that XRD with no Subject was a security risk. The future OpenID Spec will not be able to use the webfinger protocol (which according to current thinking it may want to).
In any case an "Identity Resource Descriptor", without a Subject to describe it, is entirely meaningless to me. So a new identity Layer for XRD is called for that mandates the use of <Subject> in all Identity Resource Descriptors. (IRD's).
On Thu, Oct 22, 2009 at 8:46 AM, John Bradley <ve7jtb@...> wrote:
I suppose if we were starting fresh we could have called it RDML.
I don't know that there is a meaningful distinction between a document format like OpenDocument and meta-markup language like SAML. Technically they are the same.
The XRI-TC will also be producing a XRI 3.0 spec that will use this updated XRD document specification.
Webfinger and others may also produce processing specifications for XRD or profiles of XRD.
XRD is NOT an identifier.
XRDS as currently used in openID discovery stands for eXtesable Resource Descriptor Sequence.
Yadis never made any use of the Sequence feature so we made it optional.
Hense the main document format spec is now called XRD and not XRDS.
I know people are planning on using it with a multitude of different identifiers including email addresses.
It is still XML and the document is a meta-data descriptor not an identifier.
John B.
On 2009-10-21, at 11:13 PM, Santosh Rajan wrote:
In other words now you are saying that XRD is another markup language like HTML and SAML. In which case you should be calling it "XRML" for Extensible Resource Markup Language.
So what started as a "Descriptor" has morphed into a "Markup Language".
So this gives scope for someone else to write the "REAL" Extensible Resource Descriptor Specification on top of XRML.
On Thu, Oct 22, 2009 at 2:24 AM, John Bradley <ve7jtb@...> wrote:
XRD is a XML document spec.
On 2009-10-21, at 5:21 PM, John Kemp wrote:
John Bradley wrote:
It means that some protocol that is using XRD is defining the subject via some external mechanism.
So the XRD spec. is a template spec. meant to be simply incorporated by reference into other specs. I guess?
External specs can profile the XRD spec.
In the HTTP protocol case there may be an implicit subject based on the identifier that is being resolved.
As mentioned earlier, if the _subject_ of the XRD is identified (implicitly) by the same URI used to retrieve the XRD itself, then that seems rather circular.
The XML document describes a resource and provides links to associated resources.
A HTML page doesn't need to explicitly say what URI it is retrieved from in its internal markup.
Like with HTML sometimes the subject is defined by the transport or other external method.
Thanks
John B.
All normal http caching would apply in the http: case.
Sure, I'm not quibbling with caching...
In the IMI/SAML case we have discussed pushing a XRD as a assertion/claim.
In that case the subject may be the same as the saml:NameID in the containing saml:Assertion.
It could perhaps be argued that putting a xrd:Subject and signature inside a signed saml:Asertion is un-neccicary.
Suffice to say it is up to the protocol using XRD to decide what to make of a XRD without a xrd:Subject.
OK, I think I've understood ;)
Cheers,
- johnk
John B.
On 2009-10-21, at 3:09 PM, John Kemp wrote:
John Bradley wrote:
Yes a XRD can be used for identity. In that case it should be a signed XRD (with Subject)
However a XRD can be used to describe any resource (URI).
What does it mean then (in XRD terms) if an XRD doesn't identify the resource it describes (ie. it doesn't have a subject)?
- johnk
-- http://hi.im/santosh
-- http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
smime.p7s (3K) 