[OpenID] host-meta and "acct:"

Sun Nov 1 15:41:05 UTC 2009

If you look at the XML DSig spec there is no association with any content of
the signed XML Doc itself. But I must admit my knowledge of XML DSig is
pretty rusty.

On Sun, Nov 1, 2009 at 8:55 PM, Peter Williams <home_pw at msn.com> wrote:

>  The xml:id in the attribute grammar for the XRD element is still needed
> for the optional digital signing feature. (Using xml:id is how xml dig sig
> resolvers work, by default; so the library know which bit of the XML
> document they are typically a part of they need to hash). On these grounds,
> it’s not a ROTFL issue (*).
>
>
>
> One has to be careful when signing things playing the role of certificates
> (vs any other class of signed type). One needs to get the references right.
> (Go see how in XRI 2.0 the xml:id is in both the certified name as well as
> in  signature’s own metadata referring to the XMl element to be signed).
>
>
>
> When I did the XRI/XRD trusted resolver coding (basically, just finishing
> off what someone else had mostly already done in the openxri java source
> tree), I used the default resolver of the apache dig sig library to resolve
> the xml:id field in the DOM tree representing the XRD typed value.
>
>
>
> When I did later experimented with my own resolvers built on the above
> success (and obviously no conforming to any standard), I used the http
> resolver from the apache dig sig library, initially. This is when I started
> wondering… well is the fragment on that http URI essentially playing the
> role of xpointer (which can point to such as xml:id in an incoming stream)?
>
>
>
> Then I got into semweb, which teaches not to fall into the xpointer type of
> trap, and let metadata describe what that http name is all about. Don’t
> point at format level constructs by address; do refer to semantic constructs
> by name.
>
>
>
> This all made sense (since dig sigs typically are semantically-unaware, and
> properly act on serialization formats (i.e. its propert to use an xml:id
> class reference). But, then I got into “higher” xml-design issues address
> semantic-security claims - where the blob signer signs not the value in
> question but merely a outlier value tied to the signature. It then refers to
> X. X are commonly security tokens bound to SOAP headers (see the ws-security
> world). But… X can be also be seen as a descriptor – i.e. metadata that
> describes external resources using resource description frameworks (be they
> XRDs, or RDFs).So it became fun to sign an XRD, where the XRD describes the
> semantic-security of other XRDs. But, I was just playing around. So… ignore!
>
>
>
> (*) xml dsig is a ROTFL matter, since it was born out of rejection of the 2
> paragraphs ISO took to specify how to canonicalize BER-encoded TLVs. The
> DARPA folks trained in cold war doctrine hated it (mostly because it was ISO
> defined, where ISO was evil by definition, since it included evil commie
> contributions). SO… the mindset helped engender what we now have…in the xml
> dsig world (where it takes entire books to explain its canonicalization
> process …based on pattern matching). While it would make sense if anyone
> used xmldsig in “intelligent mode”, it doesn’t in practice make sense: as
> folks only typically use Xml-dsig for purposes identical with the thing that
> took ISO 2 paragraphs to describe!
>
>
>
> But I think it’s all ultimately working out for the better. It is time we
> dumped the ASN.1-signed cert, and moved to a signed XRD  that looks like at
> least something design during the lifetime of the web! Ideally we would move
> straight to a signed graph, but I dont see much evidence of that happening
> soon (because of canoncalization issues, again!)
>
>
>
>
>
>
>
>
>
> *From:* Santosh Rajan [mailto:santrajan at gmail.com]
> *Sent:* Sunday, November 01, 2009 6:24 AM
> *To:* Peter Williams
> *Cc:* general at openid.net
> *Subject:* Re: [OpenID] host-meta and "acct:"
>
>
>
> Hehe Peter, another worm out of the XRD can. Why does XRD 1.0 need to
> define a xml:id for XRD, given that it is the root element of the XRD, there
> can only be one?
>
> ROTFL if anyone has forgotten this acronym, it is "Rolling ON The Floor
> Laughing".
>
> On Sun, Nov 1, 2009 at 3:15 AM, Peter Williams <home_pw at msn.com> wrote:
>
>
> Im tempted to say that the xml:id they used (in the abandoned initiative) a
> relic of the days when folks were still thinking about simplifing a
> sequence
> of XRDs, and the file recovered might need the locator to point out a
> particular one of several i the file (by denoting the xml:id on the XRD
> level element.)
>
> Be interesting to see if LRDD or webfinger has a non HTTP locator concept
> (based on that kind of xpointer-like URI). presumably it would only point
> to
> such as a "see also other XRD" location, rather than point out a
> sub-element
> (such as a particular link). This could retain from the XRI days something
> of what used to be attached to the old ref (vs redirect) signal - and be
> used to the same management/authority transfer issues.
>
>
>
>
> Peter Williams wrote:
> >
> > I compared the work product you referenced with
> > http://xrds-simple.net/core/1.0/ (an abandoned work).
> >
> > Just note the sheer difference in writing style! While staying within the
> > scope of the IETF work item, the I-D will ideally go back to the mixed
> > description/specification style of the pro-genitor work.
> >
> > Once one becomes a formal WG chair, it's tempting to be so concise and
> > embue such logical correctness into English terms while specification
> > writing that it ends up sounding like one of those immortal OSI standards
> > from CCITT/ISO - written in a technical language that only 3 people in
> the
> > world could speak natively. And they all sat on the committee.
> >
> > The earlier work I cited does address an issue I dont understand - once
> > cast into current XRD 1.0 and host-meta terms. See
> > http://xrds-simple.net/core/1.0/#go_fetch (last paragraph). The topic is
> > refering to elements of an XRD, given the locator url and its fragments.
> >
> > The problem I had initially with your criticism, if you recall, had
> > ignorant ol' me focussing on the XRD.Link.Subject (vs XRD.Subject). I
> > wanted the URI (with fragment) to refer to a particular link element, in
> > order that the metadata in the link acted as descriptor for that (naming)
> > URI. This seemed to align XRD and openid identifiers with semweb. This
> > would allow us all to observe only 1 religion about names and addresses.
> >
> > In the abandoned work, fragments on (I think) "returned" locators in such
> > as the HTTP Response X-XRDS-Locator URI (or a meta's http-equiv content
> > value) could have fragments, which might have pointed to a particular
> > element link within the XRD, once retrieved. The fragments had seemingly
> > special relationship to the xml:id value (an XML construct) on the link
> > element rather than the link.subject (an XRD construct) in the link
> > markup.
> >
> > For my part, I now struggle on that topic with the current proposal: what
> > concepts got dropped or recast in new form? Things start to swirl.
> >
> > Was the XRDS-Locator different to a 301, 302 or 303, in some subtle way?
> > Was there some inner subtlety about using xml:id (given its relationship
> > to DOM3 trees)? Was there a hookup with issues of xml dsig signing (and
> > its default resolvers)? Did the whole issue just disappear? if so, why
> and
> > what cost?
> >
> > Some of this context is what the IETF I-D needs to bring back, rather
> than
> > be so parsimonious and doctrinal about domains are XRi-like authorities,
> > authorities in URI schemes are an embodiment of XRI-like authorities,
> > domains and domain-names have a mystical relationships to authority
> > fields scheme (and thence to the authorites governing an RDF graph
> > node)..... cocnepts that only the higher initiates in the identity gang
> > can comprehend.
> >
> >
> >
> >
> >
> >
> >
> > http://xrds-simple.net/core/1.0/
> >
> >
> >
> >
> >
> > Santosh Rajan wrote:
> >>
> >> http://www.ietf.org/id/draft-hammer-hostmeta-01.txt
> >>
> >> If you have read the spec above, you will wonder where did the "acct:"
> >> scheme come from. It came from webfinger. The host-meta spec has been
> >> work in progress for a while now. Its predecessor was the "site-meta"
> >> spec. The idea of webfinger came later, in may 2009,and the idea of
> >> "acct:" about two months back. Given that webfinger is to follow
> >> host-meta, the question is "How come host-meta is following
> >> webfinger?".
> >>
> >> Think about it. There is an obvious attempt to legitimize the "acct:"
> >> scheme here. That is not a bad idea. I like it actually. Consider
> >> this. If I type "acct:santrajan at gmail.com <acct%3Asantrajan at gmail.com>
> >> <acct%3Asantrajan at gmail.com <acct%253Asantrajan at gmail.com>>" into my
> browser location bar, my browser
> >> would retrieve my XRD. Now this is an extreme example. But I hope you
> >> get the idea. If not please ask me.
> >>
> >> Unfortunately I have a problem with this idea, even though I like it,
> >> this is not the way to do it. The problem is that if you want to
> >> legitimize "acct:" you need to be a software engineer contortionist.
> >> You need to "Reject" Subject from the host-meta, and you need to add
> >> "Scope" into the host-meta.
> >>
> >> My contention is that if you really want to this, (and I like the
> >> idea), let us get all the DNS, w3c folk on board and do it. Doing it
> >> via the "backdoor" is going to cause more harm to the "identity
> >> movement" than good.
> >>
> >>
> >> --
> >> 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://old.nabble.com/host-meta-and-%22acct%3A%22-tp26079872p26146197.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
>
>

-- 
http://hi.im/santosh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091101/eab8e270/attachment.htm>