[OpenID] Comment on new Draft host-meta

[Santosh Rajan]

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.html
> 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/20091026/8318200d/attachment.htm>