[OpenID] Comment on new Draft host-meta

Mon Oct 26 06:58:44 UTC 2009

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 at gmail.com] 
Sent: Sunday, October 25, 2009 9:36 PM
To: Peter Williams
Cc: general at openid.net
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 at msn.com> 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
>

> _______________________________________________
> 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-tp26036844p26051937.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/20091025/1974f10a/attachment-0001.htm>