[OpenID] Comment on new Draft host-meta

Sun Oct 25 21:21:51 UTC 2009

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.