extending host-meta beyond IETF extensions; ws-security policy like rules
|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
 |
extending host-meta beyond IETF extensions; ws-security policy like rules
by Peter Williams
::
Rate this Message:
|
|
|
Re: extending host-meta beyond IETF extensions; ws-security policy like rules
by Santosh Rajan
::
Rate this Message:
|
|
|
Re: extending host-meta beyond IETF extensions; ws-security policy like rules
by Peter Williams
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...] 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@...>
wrote:
_______________________________________________ general mailing list general@... http://lists.openid.net/mailman/listinfo/openid-general |
| Free embeddable forum powered by Nabble | Forum Help |
