[OpenID] Comment on new Draft host-meta
Peter Williams
home_pw at msn.com
Sun Oct 25 04:40:02 UTC 2009
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 at gmail.com]
Sent: Saturday, October 24, 2009 9:20 PM
To: Peter Williams
Cc: general at openid.net
Subject: Re: [OpenID] 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
<Subject>dns:example.com</Subject>
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 at msn.com> 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}
<http://meta.example.com?uri=%7buri%7d> </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 at lists.openid.net
> 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.htm
l
Sent from the OpenID - General mailing list archive at Nabble.com.
_______________________________________________
general mailing list
general at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
--
http://hi.im/santosh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091024/b71dc008/attachment-0001.htm>
More information about the general
mailing list