[OpenID] host-meta and "acct:"

Sun Nov 1 16:13:49 UTC 2009

Yes. Only the XRD element has an xml:id attribute, schematically. But I
could not detect your point, of saying this fact.

And, a subject name is about an XRD in a context (in general). One such
context is the native signing/trust model (if used).

In the secured variant, the signature metadata has internal an reference
within the stream representing the value. (That's just how xml dsig works.,
irrespective of XRD typing). Csnider now the the security model of XRD vs
blob signing (where the additional security controls make the XRD into a
certificate, essentially) the referencing model is reinforced: the subject
has to refer to the same internal-stream identifier as was resolved by the
xml dsig library.

Its not that the xmldsig library has to confirm/validate the subject. That's
the function of the validation logic attached to the XRD type itself, as its
constructed from the stream. That logic implement the security model of the
type (XRD).

I'm going to  assume that the next generation of XRD library (moving  beyond
openxri's initial attempt) will have at least two factories: one derived
from the specification of an unsigned XRD type, and one for signed types.
The factory for signed types will construct class instances that can enforce
the xrd.subject rules. The more basic factory will not. IN fact, an instance
as it constructs from the stream will throw an exception if the subject
field is present (according to todays profile spec).

AS I said once before, I think you are on the right tack challenging the
IETF writeup on xrd.subject . Its just got the wrong focus. It's not that it
MUST always exist per se, but when it does exist (in the signed variety),
IETF should be defining the profile for that  variant too. In that way, the
conflicts between the issues of context-free XRDs and the issues signed XRD
can be resolved, and folks know what to do. when signing host-metas. 

From: Santosh Rajan [mailto:santrajan at gmail.com] 
Sent: Sunday, November 01, 2009 7:59 AM
To: Peter Williams
Cc: general at openid.net
Subject: Re: [OpenID] host-meta and "acct:"

Hey Peter, please note that the xml:id refers only XRD root element as per
the XRD 1.0 spec.

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

Its (arguably) better that the ASN.1 SIGNED macro it replaced. That's
because one get to insert various value/type resolvers into the process
(which existed in theory in the ASN.1 days, but not in reality). Its
obviously real, in the XML tooling era.

Now.remember the comment that xrd.subject is REQUIRED n signed XRDs? Now you
have the explanation! The subject has to bear the xml:id (so one cannot
spoof historical references, when the hash algorithm's trength starts to
fail in the future). Now, the crypto types will tell you to ensure there is
lot of redundancy in the id component o the xml:id, much like in VeriSign
serial numbers there is also lots of redundancy - preparing for the day when
the particular cipher starts to fails completely (like MD5) and folks get a
much smaller search space to attack you on!

Peter.

From: Santosh Rajan [mailto:santrajan at gmail.com] 
Sent: Sunday, November 01, 2009 7:41 AM

To: Peter Williams
Cc: general at openid.net
Subject: Re: [OpenID] host-meta and "acct:"

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
<mailto:acct%3Asantrajan at gmail.com> 
>> <acct%3Asantrajan at gmail.com <mailto: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

-- 
http://hi.im/santosh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091101/80d6da89/attachment-0001.htm>