|
Comment on new Draft host-meta
Quoting from "host-meta document SHOULD NOT include the 'Subject' or 'Alias' XRD
elements since these elements require a valid URI to identify the
resource being described, which is not available for the host-meta
scope."
Yet you have taken the very same URI's, that should have been in the Subject and Alias fields to begin with, split them into scheme and authority, stuck them into a new "Scope" element and embelished it with a new namespace to give it more legitimacy. Logically i dont see any difference from using the Subject and Alias.
"not available for the host-meta scope" is very different from "not available for the host-meta". You cannot justify ignoring the Subject of the XRD, based on its "Scope". The Subject of an XRD is about the XRD itself and not its scope.
The host-meta is not some "Thing" that resides in somebody's backyard, so that it cannot have a URI to identify it. As for differentiating the host-meta from the actual URL resource, haven't we already done it with the ".well-known" path? There is no valid justification to ignore the Subject here.
As for your use of "authority", i see a couple of problems using it. 1) "authority" has a "userinfo" part that will break your usage of it in this context.
2) URN's do not have a authority part. scheme="acct", authority=" yahoo.com" is meaning less. --
http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Comment on new Draft host-meta
Santosh:
Take the first example:-
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns=' http://docs.oasis-open.org/ns/xri/xrd-1.0' xmlns:host-meta=' http://host-meta.net/ns/1.0'>
<host-meta:Scope scheme='http' authority='example.com' />
<host-meta:Scope scheme='http' authority='www.example.com' />
<Link>
<Title xml:lang='en-us'>Site License Policy</Title>
<Rel>license</Rel>
<URI> http://example.com/license</URI>
</Link>
<Link>
<Title xml:lang='en-us'>Resource Descriptor</Title>
<Rel>describedby</Rel>
<URITemplate> http://meta.example.com?uri={uri}</URITemplate>
</Link>
</XRD>
If I use my old-for-new interpretation (which uses what I mostly understood from the XRI model in its era):-
This XRD has no XRD.subject. This means there is no named XRI-style-authority bound to this XRD. Ok. So its an anonymous XRI-style-authority. (No big deal in graph theory, where anonymous nodes abound.)
But, rather than be bound to any named XRI-style-authority, the XRD does have scope - declared using some IETF-defined XRD extension vocabulary for scope rules. In my mental model, the scope is a simple identifier class pattern - that defines a set of XRI-style-authorities to which this XRD is bound. (In graph theory an inverse functional relation for names bound to this XRI-style-authority. No big deal.)
From what I know of the old XRI algebra (and its polyarchical basis), several named XRI-style-authorites could always share an actual XRD. So, I dont find the notion of scope being used to bind several XRI-style-authority to 1 XRD particularly strange. Its an applciation of the the whole synonym thing - that made XRI so interesting to start with. (again, none of this is particular weird in graph theory, where any node can have n self-referring arcs with unique names)
So, the XRD attaches to all XRI-style-authorities (x elementOf X) where any name/identifer x meets the scope pattern (of which there are 2). The identifier form of x is an http URIs (see scope rules), which (as usual) have a scheme and URI-authority component (circa 1994). (Nothing hard here, but a bit of algebra gives us a formal variable to now play with in other formulae.)
in the XRD (now implicitely late-bound to probably multuple XRI-style-authorities meeting the scope patterns) there are two SEPs (sorry, I MUST learn to say "links").
One link has a static URI locating copyright metadata, as declared in its relationship field. I can GUESS that host-meta extension defines some semantics that declare that the linked metadata (an XRD document, I assume) applies to any and all XRI-style-authorities x...matching the scope patterns. (Its a guess, but seems reasonable. if its right, that was not hard: here is the copyright file that is incorporatde by reference into any resource whose uri=x, where x satisfied the scope rules)
Another SEP/link has a URI template. It seems to say: given the uri x identifying any 1 of the XRI-style-authority matching the scope patterns, additional metadata about that uri x can be found by querying http://meta.example.com?uri=x. (Now that all Peter's guess, but none of it seems hard or unreasonable. This is the same model as Henry gave about foaf metadata describing the URL at which the foaf document bearing the metadata can be retrieved.)
Now, I have to say that I found the writing in the internet-draft bizarre, unapproachable, aloof and overly pseudo-intellectualized.
The example however speaks for itself and (formal writing issues aside) seems obvious and useful.
Now IGNORE my interpretative basis (as its all wrong, apparently). Strangely, though, it makes perfect sense - which is far more than RFC's written introduction did.
Santosh Rajan wrote:
Quoting from
http://www.ietf.org/id/draft-hammer-hostmeta-01.txt"host-meta document SHOULD NOT include the 'Subject' or 'Alias' XRD
elements since these elements require a valid URI to identify the
resource being described, which is not available for the host-meta
scope."
Yet you have taken the very same URI's, that should have been in the Subject
and Alias fields to begin with, split them into scheme and authority, stuck
them into a new "Scope" element and embelished it with a new namespace to
give it more legitimacy. Logically i dont see any difference from using the
Subject and Alias.
"not available for the host-meta scope" is very different from "not
available for the host-meta". You cannot justify ignoring the Subject of the
XRD, based on its "Scope". The Subject of an XRD is about the XRD itself and
not its scope.
The host-meta is not some "Thing" that resides in somebody's backyard, so
that it cannot have a URI to identify it. As for differentiating the
host-meta from the actual URL resource, haven't we already done it with the
".well-known" path? There is no valid justification to ignore the Subject
here.
As for your use of "authority", i see a couple of problems using it.
1) "authority" has a "userinfo" part that will break your usage of it in
this context.
2) URN's do not have a authority part. scheme="acct", authority="yahoo.com"
is meaning less.
--
http://hi.im/santosh_______________________________________________
general mailing list
general@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general-----
Santosh Rajan
http://santrajan.blogspot.com
|
|
Re: Comment on new Draft host-meta
Hey Peter, Nice to see you back :-)
I can understand your point. I don't have a problem with host-meta having a "Scope". My problem is that it can't replace the Subject.
I am convinced that any spec that allows an XRD without a Subject, has a hole in it, big enough to sail an aircraft carrier through.
The reason why the host-meta does not have a Subject, is not so much because conceptually it does not have one. On the other hand it is because no one has come up with an agreeable Subject for everyone. The best one I have seen so far is
I don't see a problem in adding the above Subject to the host-meta XRD. Now if you "really" need a <Scope> over and above the <Subject>, I am Ok with that. Even though I believe a judicious use of a Subject and Aliases will obviate the need for a Scope.
On Sun, Oct 25, 2009 at 8:58 AM, Peter Williams <home_pw@...> wrote:
Santosh:
Take the first example:-
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'
xmlns:host-meta='http://host-meta.net/ns/1.0'>
<host-meta:Scope scheme='http' authority='example.com' />
<host-meta:Scope scheme='http' authority='www.example.com' />
<Link>
<Title xml:lang='en-us'>Site License Policy</Title>
<Rel>license</Rel>
<URI>http://example.com/license</URI>
</Link>
<Link>
<Title xml:lang='en-us'>Resource Descriptor</Title>
<Rel>describedby</Rel>
<URITemplate>http://meta.example.com?uri={uri}</URITemplate>
</Link>
</XRD>
If I use my old-for-new interpretation (which uses what I mostly understood
from the XRI model in its era):-
This XRD has no XRD.subject. This means there is no named
XRI-style-authority bound to this XRD. Ok. So its an anonymous
XRI-style-authority. (No big deal in graph theory, where anonymous nodes
abound.)
But, rather than be bound to any named XRI-style-authority, the XRD does
have scope - declared using some IETF-defined XRD extension vocabulary for
scope rules. In my mental model, the scope is a simple identifier class
pattern - that defines a set of XRI-style-authorities to which this XRD is
bound. (In graph theory an inverse functional relation for names bound to
this XRI-style-authority. No big deal.)
>From what I know of the old XRI algebra (and its polyarchical basis),
several named XRI-style-authorites could always share an actual XRD. So, I
dont find the notion of scope being used to bind several XRI-style-authority
to 1 XRD particularly strange. Its an applciation of the the whole synonym
thing - that made XRI so interesting to start with. (again, none of this is
particular weird in graph theory, where any node can have n self-referring
arcs with unique names)
So, the XRD attaches to all XRI-style-authorities (x elementOf X) where any
name/identifer x meets the scope pattern (of which there are 2). The
identifier form of x is an http URIs (see scope rules), which (as usual)
have a scheme and URI-authority component (circa 1994). (Nothing hard here,
but a bit of algebra gives us a formal variable to now play with in other
formulae.)
in the XRD (now implicitely late-bound to probably multuple
XRI-style-authorities meeting the scope patterns) there are two SEPs (sorry,
I MUST learn to say "links").
One link has a static URI locating copyright metadata, as declared in its
relationship field. I can GUESS that host-meta extension defines some
semantics that declare that the linked metadata (an XRD document, I assume)
applies to any and all XRI-style-authorities x...matching the scope
patterns. (Its a guess, but seems reasonable. if its right, that was not
hard: here is the copyright file that is incorporatde by reference into any
resource whose uri=x, where x satisfied the scope rules)
Another SEP/link has a URI template. It seems to say: given the uri x
identifying any 1 of the XRI-style-authority matching the scope patterns,
additional metadata about that uri x can be found by querying
http://meta.example.com?uri=x. (Now that all Peter's guess, but none of it
seems hard or unreasonable. This is the same model as Henry gave about foaf
metadata describing the URL at which the foaf document bearing the metadata
can be retrieved.)
Now, I have to say that I found the writing in the internet-draft bizarre,
unapproachable, aloof and overly pseudo-intellectualized.
The example however speaks for itself and (formal writing issues aside)
seems obvious and useful.
Now IGNORE my interpretative basis (as its all wrong, apparently).
Strangely, though, it makes perfect sense - which is far more than RFC's
written introduction did.
Santosh Rajan wrote:
>
> Quoting from
>
> http://www.ietf.org/id/draft-hammer-hostmeta-01.txt
>
> "host-meta document SHOULD NOT include the 'Subject' or 'Alias' XRD
> elements since these elements require a valid URI to identify the
> resource being described, which is not available for the host-meta
> scope."
>
>
> Yet you have taken the very same URI's, that should have been in the
> Subject
> and Alias fields to begin with, split them into scheme and authority,
> stuck
> them into a new "Scope" element and embelished it with a new namespace to
> give it more legitimacy. Logically i dont see any difference from using
> the
> Subject and Alias.
>
>
> "not available for the host-meta scope" is very different from "not
> available for the host-meta". You cannot justify ignoring the Subject of
> the
> XRD, based on its "Scope". The Subject of an XRD is about the XRD itself
> and
> not its scope.
>
>
> The host-meta is not some "Thing" that resides in somebody's backyard, so
> that it cannot have a URI to identify it. As for differentiating the
> host-meta from the actual URL resource, haven't we already done it with
> the
> ".well-known" path? There is no valid justification to ignore the Subject
> here.
>
>
> As for your use of "authority", i see a couple of problems using it.
> 1) "authority" has a "userinfo" part that will break your usage of it in
> this context.
> 2) URN's do not have a authority part. scheme="acct",
> authority=" yahoo.com"
> is meaning less.
>
> --
> http://hi.im/santosh
>
> general mailing list
> general@...
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
> -----
>
> Santosh Rajan
> http://santrajan.blogspot.com
>
--
View this message in context: http://www.nabble.com/Comment-on-new-Draft-host-meta-tp26036844p26045022.html
Sent from the OpenID - General mailing list archive at Nabble.com.
_______________________________________________
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: Comment on new Draft host-meta
Some parts of this message have been removed.
Learn more about Nabble's security policy.
The scope not scope and subject not subject is the same pattern
as can be found in the semweb’s foaf world (where they do exactly the
same thing).
If I play arbiter, if you swap the contentious word security
for trust, I don’t think the folks writing XRD spec will disagree with
you.
They have already admitted that subject is mandatory for trusted
XRD (under some trust model is tied to verifying the crypto-signatures).
So they are admitting that subject is required as security
control, for trusted XRD.
Yes, that implies that there can be no trusted version of
host-meta (if its true that the profile mandates that subject is always
missing). I didn’t bother reading any more of the I-D to get to its
security section, since its obscure writing was making me ill.
Not every XRD has to be a trusted XRD.
Presumably, host-meta profiled XRD will use security mechanism
OTHER than trusted XRD (i.e. signatures). One can guess – knowing IAB
types - there are plans to exploit secure DNS, and tie the authority component of
the anything matching the scopes to domain names, which have their own metadata
in the signed DNS resource record (of course).
From: Santosh Rajan [mailto:santrajan@...]
Sent: Saturday, October 24, 2009 9:20 PM
To: Peter Williams
Cc: general@...
Subject: Re: [OpenID] Comment on new Draft host-meta
Hey Peter,
I can understand your point. I don't
have a problem with host-meta having a "Scope". My problem is that it
can't replace the Subject.
I am convinced that any spec that
allows an XRD without a Subject, has a hole in it, big enough to sail an
aircraft carrier through.
The reason why the host-meta does
not have a Subject, is not so much because conceptually it does not have one.
On the other hand it is because no one has come up with an agreeable Subject
for everyone. The best one I have seen so far is
I don't see a problem in adding the
above Subject to the host-meta XRD. Now if you "really" need a
<Scope> over and above the <Subject>, I am Ok with that. Even
though I believe a judicious use of a Subject and Aliases will obviate the need
for a Scope.
On Sun, Oct 25, 2009 at 8:58 AM,
Peter Williams <home_pw@...>
wrote:
Santosh:
Take the first example:-
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'
xmlns:host-meta='http://host-meta.net/ns/1.0'>
<host-meta:Scope scheme='http' authority='example.com' />
<host-meta:Scope scheme='http' authority='www.example.com' />
<Link>
<Title xml:lang='en-us'>Site
License Policy</Title>
<Rel>license</Rel>
<URI>http://example.com/license</URI>
</Link>
<Link>
<Title xml:lang='en-us'>Resource
Descriptor</Title>
<Rel>describedby</Rel>
<URITemplate>http://meta.example.com?uri={uri}</URITemplate>
</Link>
</XRD>
If I use my old-for-new interpretation (which uses what I mostly understood
from the XRI model in its era):-
This XRD has no XRD.subject. This means there is no named
XRI-style-authority bound to this XRD. Ok. So its an anonymous
XRI-style-authority. (No big deal in graph theory, where anonymous nodes
abound.)
But, rather than be bound to any named XRI-style-authority, the XRD does
have scope - declared using some IETF-defined XRD extension vocabulary for
scope rules. In my mental model, the scope is a simple identifier class
pattern - that defines a set of XRI-style-authorities to which this XRD is
bound. (In graph theory an inverse functional relation for names bound to
this XRI-style-authority. No big deal.)
>From what I know of the old XRI algebra (and its polyarchical basis),
several named XRI-style-authorites could always share an actual XRD. So, I
dont find the notion of scope being used to bind several XRI-style-authority
to 1 XRD particularly strange. Its an applciation of the the whole
synonym
thing - that made XRI so interesting to start with. (again, none of this is
particular weird in graph theory, where any node can have n self-referring
arcs with unique names)
So, the XRD attaches to all XRI-style-authorities (x elementOf X) where any
name/identifer x meets the scope pattern (of which there are 2). The
identifier form of x is an http URIs (see scope rules), which (as usual)
have a scheme and URI-authority component (circa 1994). (Nothing hard here,
but a bit of algebra gives us a formal variable to now play with in other
formulae.)
in the XRD (now implicitely late-bound to probably multuple
XRI-style-authorities meeting the scope patterns) there are two SEPs (sorry,
I MUST learn to say "links").
One link has a static URI locating copyright metadata, as declared in its
relationship field. I can GUESS that host-meta extension defines some
semantics that declare that the linked metadata (an XRD document, I assume)
applies to any and all XRI-style-authorities x...matching the scope
patterns. (Its a guess, but seems reasonable. if its right, that was not
hard: here is the copyright file that is incorporatde by reference into any
resource whose uri=x, where x satisfied the scope rules)
Another SEP/link has a URI template. It seems to say: given the uri x
identifying any 1 of the XRI-style-authority matching the scope patterns,
additional metadata about that uri x can be found by querying
http://meta.example.com?uri=x.
(Now that all Peter's guess, but none of it
seems hard or unreasonable. This is the same model as Henry gave about foaf
metadata describing the URL at which the foaf document bearing the metadata
can be retrieved.)
Now, I have to say that I found the writing in the internet-draft bizarre,
unapproachable, aloof and overly pseudo-intellectualized.
The example however speaks for itself and (formal writing issues aside)
seems obvious and useful.
Now IGNORE my interpretative basis (as its all wrong, apparently).
Strangely, though, it makes perfect sense - which is far more than RFC's
written introduction did.
Santosh Rajan wrote:
>
> Quoting from
>
> http://www.ietf.org/id/draft-hammer-hostmeta-01.txt
>
> "host-meta document SHOULD NOT include the 'Subject' or 'Alias' XRD
> elements since these elements require a valid URI to identify
the
> resource being described, which is not available for the
host-meta
> scope."
>
>
> Yet you have taken the very same URI's, that should have been in the
> Subject
> and Alias fields to begin with, split them into scheme and authority,
> stuck
> them into a new "Scope" element and embelished it with a new
namespace to
> give it more legitimacy. Logically i dont see any difference from using
> the
> Subject and Alias.
>
>
> "not available for the host-meta scope" is very different from
"not
> available for the host-meta". You cannot justify ignoring the Subject
of
> the
> XRD, based on its "Scope". The Subject of an XRD is about the
XRD itself
> and
> not its scope.
>
>
> The host-meta is not some "Thing" that resides in somebody's
backyard, so
> that it cannot have a URI to identify it. As for differentiating the
> host-meta from the actual URL resource, haven't we already done it with
> the
> ".well-known" path? There is no valid justification to ignore
the Subject
> here.
>
>
> As for your use of "authority", i see a couple of problems using
it.
> 1) "authority" has a "userinfo" part that will break
your usage of it in
> this context.
> 2) URN's do not have a authority part. scheme="acct",
> authority="yahoo.com"
> is meaning less.
>
> --
> http://hi.im/santosh
>
>
_______________________________________________
> general mailing list
> general@...
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
> -----
>
> Santosh Rajan
> http://santrajan.blogspot.com
>
--
View this message in context: http://www.nabble.com/Comment-on-new-Draft-host-meta-tp26036844p26045022.html
Sent from the OpenID - General mailing list archive at Nabble.com.
_______________________________________________
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: Comment on new Draft host-meta
concerning the abstract argument at http://hueniverse.com/2009/07/users-vs-identity-providers-in-openid/the host-meta draft seems to hinge on a core argument. It asserts as conclusion that a URI really cannot identify a host (and thus one needs the IETF standard to redress what the web architects have failed to do). It implies that openid community has been barking up the wrong tree in using a URI to identify an OP provider. ONLY a DOMAIN NAME can really identity a host (and thus an OP provider)
I have to say that I'm struggling to accept that argument as sound.
the assumption that a URI cannot really identify an OP Provider is hard to accept. It seems to fly in the face of what the semweb metadata model is all about.
That one must _necessarily_ equate an OP Provider with a "host" (and thus a domain name), seems bizarre. As an option (and an opportunity), it seems fine.
So far, i find myself intuitively objecting on the grounds that no such argument was necessary in the SAML world (which had some of really picky, identity pedants attached to its autoring, editing and review). If the IDP's entityname in the SAML world happens to be an URL, one COULD simply (and Shibboleth software DOES) use the URI to obtain the SAML metadata from an HTTP server. There was and is no "necessity" for complex arguments about hosts, providers, and what URIs can and cannot do (if one equates an IDP Provider with a "host"). Picking up metadata about an IDP named by URL is done every day, and I cannot find any argument of theoretical issues with it.
Now, what I am missing? Is there analysis of the argument when applied to SAML2 and Shibboleth (vs OpenID)?
Why would the argument hold for openid asserting parties (and OP Providers), but not for SAML asserting parties (and IDP providers)?
|
|
Re: Comment on new Draft host-meta
If I were designing a set of tags that could serve multiple world of (i) "identity authorities" issuing identifiers, and (ii) "resource authorities" issuing (resource) identifiers, Id make sure it was flexible enough for that purpose.
Perhaps we consider the xrd.subject issue in that light. (it works for me, down here in ignorance land).
subjects are more aligned wth that use of XRD we are most familiar with (from the world of XRI): identity naming, by registries.
In the contrasting world of resource authorities, the xrd.subject is less germane.
Now, what we know (from the explanation Dirk gave here several months ago when announcing Googles OPs-for-domains initiative) is that there is a strange cross-over: between identity authorities and resource authorities. This occurs when one is is consider the OP-for-domains delegation issue set specifically: when can one domain's endpoints speak for the users at another? when can one locator service for metadata at domain X be an _authoritative_ source of metadata about URIs who authority domains are other than X?
If we view the host-meta use of scopes AND a URI-template in light of that discovery problem (addresing the authority of a metadata locator service to speak for identified users at another domain), perhaps its less hard to see the design motivations of the profile.
Its now no longer about a syntax issue: the rights and wrongs of tag and field design in a generic format. Rather, its an application of the tools provided by the XRD format (when extended by IETF) to let one domain speak for another, and one set of URI to be authoritatively served/represented by a provider at another URI.
So one doesnt have to enumerate all the users at the google apps domain X, when the cloud service provider is doing offloaded work for n users for the apps-domain X, use a scope... which implicitely defines the parties it speaks for. Have multiple scopes, when there is (XRI-like) a delegation of authority matter going on (during a corporate takeover , say).
what is nice is that the XRD recovered for a hosted domain or a hosted user is still available to the RP (once recovered using the URI factory in the URI template, and the metadata server. . That users XRD may (now that its been located and recovered) not actually point to the cloud hosting point.
Now, I do thing that there is a certainly * going on (I cannot decide on the word *). Though architecturally, the user XRD's links might point elsewhere, those user XRD are provisioned by parties other than the user. SO, Im not convinced the theory of user-centric control will be realized (any more than at myopenid, where the provider does NOT allow you control your user-level XRD, enabling *user-selected* domain delegation). Yes you the web-rights theoretically, but not in "reality".
What Im noting, compared to the threads n this months ago, is _is_ getting clearer.... And,... it IS being handled in repsected standards forums where lots of folks with lots of agendas get to argue the merits. It all looks pretty open... by normal measures of community standards making.
Peter.
Santosh Rajan wrote:
Quoting from
http://www.ietf.org/id/draft-hammer-hostmeta-01.txt"host-meta document SHOULD NOT include the 'Subject' or 'Alias' XRD
elements since these elements require a valid URI to identify the
resource being described, which is not available for the host-meta
scope."
Yet you have taken the very same URI's, that should have been in the Subject
and Alias fields to begin with, split them into scheme and authority, stuck
them into a new "Scope" element and embelished it with a new namespace to
give it more legitimacy. Logically i dont see any difference from using the
Subject and Alias.
"not available for the host-meta scope" is very different from "not
available for the host-meta". You cannot justify ignoring the Subject of the
XRD, based on its "Scope". The Subject of an XRD is about the XRD itself and
not its scope.
The host-meta is not some "Thing" that resides in somebody's backyard, so
that it cannot have a URI to identify it. As for differentiating the
host-meta from the actual URL resource, haven't we already done it with the
".well-known" path? There is no valid justification to ignore the Subject
here.
As for your use of "authority", i see a couple of problems using it.
1) "authority" has a "userinfo" part that will break your usage of it in
this context.
2) URN's do not have a authority part. scheme="acct", authority="yahoo.com"
is meaning less.
--
http://hi.im/santosh_______________________________________________
general mailing list
general@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general-----
Santosh Rajan
http://santrajan.blogspot.com
|
|
Re: Comment on new Draft host-meta
Peter,The purpose of the host-meta is to provide a mapping for the URI's (read Subject) of the XRD, to its actual location for retrieval. For doing this all you need is the "http" scheme for the host-meta.
The hilarious part of the whole thing is that, after jumping through all the hoops of the "DNS scheme extension", what actually retrieves the XRD (URI Template) is your good old "http" scheme.
On Mon, Oct 26, 2009 at 2:51 AM, Peter Williams <home_pw@...> wrote:
If I were designing a set of tags that could serve multiple world of (i)
"identity authorities" issuing identifiers, and (ii) "resource authorities"
issuing (resource) identifiers, Id make sure it was flexible enough for that
purpose.
Perhaps we consider the xrd.subject issue in that light. (it works for me,
down here in ignorance land).
subjects are more aligned wth that use of XRD we are most familiar with
(from the world of XRI): identity naming, by registries.
In the contrasting world of resource authorities, the xrd.subject is less
germane.
Now, what we know (from the explanation Dirk gave here several months ago
when announcing Googles OPs-for-domains initiative) is that there is a
strange cross-over: between identity authorities and resource authorities.
This occurs when one is is consider the OP-for-domains delegation issue set
specifically: when can one domain's endpoints speak for the users at
another? when can one locator service for metadata at domain X be an
_authoritative_ source of metadata about URIs who authority domains are
other than X?
If we view the host-meta use of scopes AND a URI-template in light of that
discovery problem (addresing the authority of a metadata locator service to
speak for identified users at another domain), perhaps its less hard to see
the design motivations of the profile.
Its now no longer about a syntax issue: the rights and wrongs of tag and
field design in a generic format. Rather, its an application of the tools
provided by the XRD format (when extended by IETF) to let one domain speak
for another, and one set of URI to be authoritatively served/represented by
a provider at another URI.
So one doesnt have to enumerate all the users at the google apps domain X,
when the cloud service provider is doing offloaded work for n users for the
apps-domain X, use a scope... which implicitely defines the parties it
speaks for. Have multiple scopes, when there is (XRI-like) a delegation of
authority matter going on (during a corporate takeover , say).
what is nice is that the XRD recovered for a hosted domain or a hosted user
is still available to the RP (once recovered using the URI factory in the
URI template, and the metadata server. . That users XRD may (now that its
been located and recovered) not actually point to the cloud hosting point.
Now, I do thing that there is a certainly * going on (I cannot decide on the
word *). Though architecturally, the user XRD's links might point elsewhere,
those user XRD are provisioned by parties other than the user. SO, Im not
convinced the theory of user-centric control will be realized (any more than
at myopenid, where the provider does NOT allow you control your user-level
XRD, enabling *user-selected* domain delegation). Yes you the web-rights
theoretically, but not in "reality".
What Im noting, compared to the threads n this months ago, is _is_ getting
clearer.... And,... it IS being handled in repsected standards forums where
lots of folks with lots of agendas get to argue the merits. It all looks
pretty open... by normal measures of community standards making.
Peter.
Santosh Rajan wrote:
>
> Quoting from
>
> http://www.ietf.org/id/draft-hammer-hostmeta-01.txt
>
> "host-meta document SHOULD NOT include the 'Subject' or 'Alias' XRD
> elements since these elements require a valid URI to identify the
> resource being described, which is not available for the host-meta
> scope."
>
>
> Yet you have taken the very same URI's, that should have been in the
> Subject
> and Alias fields to begin with, split them into scheme and authority,
> stuck
> them into a new "Scope" element and embelished it with a new namespace to
> give it more legitimacy. Logically i dont see any difference from using
> the
> Subject and Alias.
>
>
> "not available for the host-meta scope" is very different from "not
> available for the host-meta". You cannot justify ignoring the Subject of
> the
> XRD, based on its "Scope". The Subject of an XRD is about the XRD itself
> and
> not its scope.
>
>
> The host-meta is not some "Thing" that resides in somebody's backyard, so
> that it cannot have a URI to identify it. As for differentiating the
> host-meta from the actual URL resource, haven't we already done it with
> the
> ".well-known" path? There is no valid justification to ignore the Subject
> here.
>
>
> As for your use of "authority", i see a couple of problems using it.
> 1) "authority" has a "userinfo" part that will break your usage of it in
> this context.
> 2) URN's do not have a authority part. scheme="acct",
> authority=" yahoo.com"
> is meaning less.
>
> --
> http://hi.im/santosh
>
-- http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: Comment on new Draft host-meta
Some parts of this message have been removed.
Learn more about Nabble's security policy.
I’m not yet convinced in the “host” axiom of
the host-meta arrangement, either. But, it’s for a different reason to
that you proffer.
For me, it seems to deny what the semweb claims about a uri
being able to refer to anything (that metadata at the URI written using the rdf
metamodel will then describe). This is something the W3C TAG are going to note
(and presumably comment on to IAB). We don’t want the very same argument
presented against XRI (the web can do it natively; don’t bother) to be
used against such as the XRD host-meta profile (the semweb can do it natively; don’t
bother).
Arguably, the foaf+ssl experiment – being built according
to pure semweb theory - is showing W3C folks that perhaps semweb principles
with https MAY be able do exactly what XRD and host-meta are claiming to do (without
requiring the host axiom or the XML of XRD).
But let’s take it as a given that a uri cannot “really”
identify the concept known as a “host”. Lets then accept the proposal
that one can exploit the well-known url-factory rules (per profile of XRD) that
trivially rewrites domain names string about hosts into http URI identifiers, for
metadata of that metadata type. And lets assume DNS can confirm that the domain
name is a “governed” host, furthermore (using trusted DNS).
Providing there exists a mean (e.g. https and server certs making
domain-control assertions) to confirm that the host-meta file is bound to the
domain name of the host, now let the RP use the link rule from the recovered
document to obtain further XRD metadata for each user (but only “validly”
for those users specified in the scope rules).
Perhaps consider that the context that MIGHT be played by an
issuing authority populating xrd.subject field could be being played by the
https server (and its domain cert). In some sense, the subject field is implied
by what the socket the RP uses reports, as it confirms the identity of the server
“host” its talking to (using ssl’s record layer). Being
context free, one gets the loose coupling of files and domains, making for easier
management and provisioning by lots of parties using 80:20 management culture.
Of course, an SSL server X.509 cert or X.509 PAC COULD specify
the scope rules (and then the link template) that is present in the XRD. One
form of metadata is just as good as another, and a cert is just metadata about
a domain name these days. If one wanted, one could be dynamically stuffing the
XRD host-meta stream in an __ephemeral__ SSL server cert delivered when talking
https. Just put the XRD into that cert’s extension, signed on the fly by
the SSL ciphersuite.
From: Santosh Rajan [mailto:santrajan@...]
Sent: Sunday, October 25, 2009 9:36 PM
To: Peter Williams
Cc: general@...
Subject: Re: [OpenID] Comment on new Draft host-meta
Peter,
The purpose of the host-meta is to provide a
mapping for the URI's (read Subject) of the XRD, to its actual location for
retrieval. For doing this all you need is the "http" scheme for the
host-meta.
The hilarious part of the whole thing is
that, after jumping through all the hoops of the "DNS scheme
extension", what actually retrieves the XRD (URI Template) is your good
old "http" scheme.
On Mon, Oct 26, 2009 at 2:51 AM,
Peter Williams <home_pw@...>
wrote:
If I were designing a set of tags that could serve multiple world of (i)
"identity authorities" issuing identifiers, and (ii) "resource
authorities"
issuing (resource) identifiers, Id make sure it was flexible enough for that
purpose.
Perhaps we consider the xrd.subject issue in that light. (it works for me,
down here in ignorance land).
subjects are more aligned wth that use of XRD we are most familiar with
(from the world of XRI): identity naming, by registries.
In the contrasting world of resource authorities, the xrd.subject is less
germane.
Now, what we know (from the explanation Dirk gave here several months ago
when announcing Googles OPs-for-domains initiative) is that there is a
strange cross-over: between identity authorities and resource authorities.
This occurs when one is is consider the OP-for-domains delegation issue set
specifically: when can one domain's endpoints speak for the users at
another? when can one locator service for metadata at domain X be an
_authoritative_ source of metadata about URIs who authority domains are
other than X?
If we view the host-meta use of scopes AND a URI-template in light of that
discovery problem (addresing the authority of a metadata locator service to
speak for identified users at another domain), perhaps its less hard to see
the design motivations of the profile.
Its now no longer about a syntax issue: the rights and wrongs of tag and
field design in a generic format. Rather, its an application of the tools
provided by the XRD format (when extended by IETF) to let one domain speak
for another, and one set of URI to be authoritatively served/represented by
a provider at another URI.
So one doesnt have to enumerate all the users at the google apps domain X,
when the cloud service provider is doing offloaded work for n users for the
apps-domain X, use a scope... which implicitely defines the parties it
speaks for. Have multiple scopes, when there is (XRI-like) a delegation
of
authority matter going on (during a corporate takeover , say).
what is nice is that the XRD recovered for a hosted domain or a hosted user
is still available to the RP (once recovered using the URI factory in the
URI template, and the metadata server. . That users XRD may (now that its
been located and recovered) not actually point to the cloud hosting point.
Now, I do thing that there is a certainly * going on (I cannot decide on the
word *). Though architecturally, the user XRD's links might point elsewhere,
those user XRD are provisioned by parties other than the user. SO, Im not
convinced the theory of user-centric control will be realized (any more than
at myopenid, where the provider does NOT allow you control your user-level
XRD, enabling *user-selected* domain delegation). Yes you the web-rights
theoretically, but not in "reality".
What Im noting, compared to the threads n this months ago, is _is_ getting
clearer.... And,... it IS being handled in repsected standards forums where
lots of folks with lots of agendas get to argue the merits. It all looks
pretty open... by normal measures of community standards making.
Peter.
Santosh Rajan wrote:
>
> Quoting from
>
> http://www.ietf.org/id/draft-hammer-hostmeta-01.txt
>
> "host-meta document SHOULD NOT include the 'Subject' or 'Alias' XRD
> elements since these elements require a valid URI to identify
the
> resource being described, which is not available for the
host-meta
> scope."
>
>
> Yet you have taken the very same URI's, that should have been in the
> Subject
> and Alias fields to begin with, split them into scheme and authority,
> stuck
> them into a new "Scope" element and embelished it with a new
namespace to
> give it more legitimacy. Logically i dont see any difference from using
> the
> Subject and Alias.
>
>
> "not available for the host-meta scope" is very different from
"not
> available for the host-meta". You cannot justify ignoring the Subject
of
> the
> XRD, based on its "Scope". The Subject of an XRD is about the
XRD itself
> and
> not its scope.
>
>
> The host-meta is not some "Thing" that resides in somebody's
backyard, so
> that it cannot have a URI to identify it. As for differentiating the
> host-meta from the actual URL resource, haven't we already done it with
> the
> ".well-known" path? There is no valid justification to ignore
the Subject
> here.
>
>
> As for your use of "authority", i see a couple of problems using
it.
> 1) "authority" has a "userinfo" part that will break
your usage of it in
> this context.
> 2) URN's do not have a authority part. scheme="acct",
> authority="yahoo.com"
> is meaning less.
>
> --
> http://hi.im/santosh
>
View this message in context: http://www.nabble.com/Comment-on-new-Draft-host-meta-tp26036844p26051937.html
--
http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
