[OpenID] extending host-meta beyond IETF extensions; ws-security policy like rules

Sat Oct 31 08:49:33 UTC 2009

Yes, the first draft of the I-D needs a good rewrite. The writing style is
hurting its mission, particularly in IETF where the technical writing is
itself a premium marker of what might make it to internet standards status
(one day). But, it's only draft #1 - to be fair to the author!

This got rather long. Speed read, and don't waste more than 2 minutes on it.

I also went through a moment when I thought: hmm, if one is really going to
focus on domains (and domain-names), does it really make sense to put the
metadata in a file (rather than add RRs to DNS)? The answer was yes, on the
merits (and given the successful takeup of .crt file for certs, stored on
webservers).

-          Adding RRs to DNS will probably take a decade of work. What
sensible business community would want to wait that long?

-          Putting a file on a host, written in XML and located by
domain-name, is easy and scales to the size that  DNS scale to

-          Any admin can write a file on a web server on a well  known URI,
as can simple wizards that provision an app-domain by default (similar to
how ISP's auto-provision web farm tenants, located by host-header)

-          What admins do today in HTML to stuff 5 meta links with link
attributes in the HTML header, they can do  in XML (in an largely equivalent
markup). Yes, one has to ask: why not use RDFa for that? The answer is
probably: compatibility in spirit with openid legacy and easier
upgradability of existing libs at RPs - that don't need a full RDFa parser

-          What openid has already done with meta links in HTML and meta
links in XRD file for OP providers and their users' XRDs evidently works,
and worked for openid adoption this far. Don't fix what aint broken.

-          It's all, quite properly, a standardization of what myopenid did
already using various adhoc mechanisms, in their "for domains" rollout
model. Now everyone benefits from the standardization of techniques. This is
openness for all to see.

The thing that has really happened is innovation around the  "google apps
for domains" delegation, in which one domain can speak for another -
enabling a cloud provider to deliver OP or RP services in the name of its
app-domain. 

Beyond merely expressing the delegation between names in two administrative
regions, one then has the issue of: how does the RP know its authoritative?
We could wax lyrical how X.500 1993 standard solved this classical
identifier/domains properly in DN space (allowing for the likes of ou group
policy and federated trusts between transitive or mapped domains in Active
Directory), but that all irrelevant. Here its all motivated by the topics of
directed identity and law #4 semantics, which introduces locator and
identifier semantics that simply require more involved validation logics
than simple meta link resolution offers.

As the nature of being an OP means typically serving per user XRDs, one has
the issue of pointing at the URI where as cloud provider one serves up the
user XRDS "in the name of any one of 10 million app-domains"; ensuring the
RP can tell which user XRDs authoritatively belong to which one of the 10
million hosted app domains. 

I don't think one can pull out the user XRD locator from the app-domain
scoping, or pull out the cloud outsourcing of app-domains from the user XRD
locating, or the attributed linking from the design of the markup.  They all
go together, to address the above. Standards are about standardization, and
that's what its clearly doing.

As much as folks want to say the XRD1.0 is fundamentally different from the
XRD we all used in the YADIS period, it isn't. It is simply being unbunded
from http and XRI identifiers, and the SEP-style markup updated to now align
in markup concept with http meta links (learning from atom).

Calling an XRD a descriptor does not worry me. that's just of bit of
standard abstract metadata-speak. It's a magic word, consistent with using
conventions in English when talking in and about metamodels. Using formal
Spanish would do better than using English for this - since one has the
latinate structure to make internal lots of references within long 200 word,
multi-clause sentences. But, its being written in English, which uses
conventions, instead. Once you get used to the magic words, its short and
snappy. Pick your evil: extended latin grammar like Newton used for the laws
of physics in the 1670s , or subtle conventions for the laws of identity, in
2010.

Yes I sometimes wish the metamodel was as consistent as it was in the XRI
days ( a descriptor is metadata about an identifier), but it's not; so
there. In the case of host-meta, I find myself believing (though it only
partly says it): its "about" an domain-name - obviously an identifier. If
the author could just say what he means, rather than be so abstract!

Is one "extending DNS" by referring to a file on a web server located having
used DNS to resolve the authority component of a URI scheme when it treated
as and infact IS a domain name? No. One does the same thing in X.509 .crt
files stored on web servers, whose DNs are indexes in a directory. IETF
already standardized the latter, in some PKI RFC whose number changes every
few years. The world of NATO directories with its 300 page standard for
domain delegation within the DN-centric DIT and multi-schema metadata
distribution within "autonomous policy regions" in a  DIB .didn't collapse,
and infact didn't even blink. The internet just went around ISO, in 3
paragraphs, and stuffed an X.509 cert in a file on a webserver, where the
file is located by domain in a http URL. Ditto for crl files, trust anchors,
and trust chains.

If one failed to put a subject DN in an X.509 cert persisted to a .crt file
locatable on a well known http URI on some domain's webservers, and one then
put 5 subject alt names in that structure each using the URI name form (now
playing the role of 5 links in an XRD and even a URI "template") would the
missing subject DN matter to the semantics of X.509? No. 

Does a cert in a .crt file already have a "scheme mapping" notion? Yes. Its
called the "alt names" construct for subjects (and issuers). No patent
claims there. Though, its clearer in the host-meta conception (I think).

Does a cert in a .crt file already have the notion that URI scheme
"authorities" have jurisdictions, and can be tied of "domains" - that
"govern" _authorities_. Yes. It's called the cn=<domain> field (circa 1995)
and  the more modern conventions that place a list of domain names in an
subject alt name. No patent claims there; the cert as metadata (stuffed in a
file with a well-known file extension, stored on a webserver locatable by
http URL) already did it. No patent or PhD originality claim for that
non-invention.

If  one buys into all this (and one  views signed XRD much as a modern
signed cert with a change of format from ASN.1 to XML), then one might as
well work within its framework. Might as well now use its expressions to
address, per domain (on a "host" basis) and for each app-domain: how to
enable sreg and ax attributes to be  described using additional metadata -
hanging off the host-meta links. Then one gets to make meta-statements about
sreg and ax attributes, when treating them as "claims", that in turn drive
claim-based identity systems.

And there is the rub. This is all a web2.0 style way of doing what
VeriSIgn/IBM/Microsoft already did with ws-security following in the OSI
styles and traditions of ECMA's ROS and related security standards (and
web3.0 folks are now starting doing with secured and trusted semweb metadata
built using RESTful style). 

So what's new..? There are multiple standards to choose from, each doing the
same thing! Little has changed in 25+ years, except that its all now real
(vs paper) and only getting bigger and bigger. As one scale up, the
engineering has to re-scale with it. Lots of standards politics will be
present, as each group tries to win. As always , folks will apply rhetoric
and argumentation, to help make their case.

From: Santosh Rajan [mailto:santrajan at gmail.com] 
Sent: Friday, October 30, 2009 8:45 PM
To: Peter Williams
Cc: general at openid.net
Subject: Re: [OpenID] extending host-meta beyond IETF extensions;
ws-security policy like rules

The more I look at it, the more I can see that this whole "Scope" story is a
can (truckload?) of worms waiting to be opened.

For this the original objectives of XRD and host-meta have been changed
somewhere down the line. After the "acct:" scheme came up.

1) XRD from "descriptor" to "markup language"

2) host-meta from "simple mapper" to "extending DNS".

My suggestion is that we stick to the original objectives for "Version 1.0"
of XRD and host-meta spec, and use only the "http(s) scheme, and get this
whole thing working in the first place (acct: can be used to describe an
email like identifier in the Subject). Adding "Scope" and extending DNS etc
can be done in a later Version of the spec.

And this is not my idea. On the webfinger list, somebody from (IETF I think)
has suggested the same thing. That they develop a simple Version 1 to start
with.

Unfortunately these guys don't seem to be in a great mood to listen to
reason.

On Fri, Oct 30, 2009 at 11:51 PM, Peter Williams <home_pw at msn.com> wrote:

if one buys into host-meta, using scopes to indentity for which URI (user)
identifies this host is authoritative (particularly in  world where cloud
providers on 1  domain supports app-domains on other domains) I can see more
scope rules being required.

On an app-domain basis, and then a per-user basis, each overriding the cloud
providers scope, host-meta scopre for "authoritative sreg attributes" might
be added to the app-domain's host-meta file.

The RP might want to know which attibutes the app-domain has "verified", and
speaks for (above and beyond the cloud provider merely forwarding the values
from the users profile).

Despite having outsourced to google discovery and per-user profile
management for my app domain on my domain's URI, I app domain assert that I
legallty represent the value of sreg.website to be in compliance with my
posted policy (also hanging off of my app domains host-meta).

In all likelihood, this day and age, the policy would be an RDFa document,
so its readable by hiumans amd the machie-readable elements can express
rules in an algerab not dissimialr to ws-securitypocliy (controlling which
claims are required at which RPs, and which an IDP (i.e. app-domain, not
cloud provider) is itself will to vouch for, legally.
--
View this message in context:
http://old.nabble.com/extending-host-meta-beyond-IETF-extensions--ws-securit
y-policy-like-rules-tp26134827p26134827.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/20091031/38170139/attachment-0001.htm>