|
host-meta and "acct:"
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%3Asantrajan@..." 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@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: host-meta and "acct:"
As is typical, I actually learned something from the partial-rant: acct, and its assumed importance to the story being formulated in the standard. I had not picked that up. Im still at the point that the initiative is about URI scheme mappings... of any sort; and evaluatin the claim that a host cannot be a foaf-agent with a URI (and thus the whole orientation MUST be "all about domains" instead).
Typing xri:... at the browser bar or typing acct:... sounds nuts. 1.5 billion people are educated to type and recognize http URIs in that particular location. XRI made a good try, though. It failed (in that role).
I dont know if the histrionics about the acct: scheme were really necessary... but they made the agenda politics SOUND interesting. A little conspiracy does wonders for making threads about telematic infrsatructure evolution enjoyable. Standards and their lobbys are always about folks pursuing their agendas, which is fine so long as the process is pretty open and fun. (Its never ever 100% open. There is always a backchannel amongst the "real" insiders who are spending real cash.)
on W3C, Ive been practicising my early-learner skills trying to write a file with foaf classes, to do what host-meta does. Now therein lies some interesting politics: if RDF with foaf classes does what XRD.host-meta does, and the URI does for hosts what domains do in the IETF's host-meta conception of the world, will that help or hinder bringing W3C types on board?
Also, as foaf+ssl's assertion of a WebID in SSL client certs ties in with the use of https server certs on the (webid-derived) "host" site delivering the user's foaf file (which then plays the role of the openid assertion message, when pulled over the https backchannel), does this "host's" rules for cloud outsourcing of app-domains written up in rdf/foaf help or hinder W3C endorsement of XRD (and the host-meta profile) ?
Santosh Rajan wrote:
http://www.ietf.org/id/draft-hammer-hostmeta-01.txtIf 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@gmail.com
<acct%3Asantrajan@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@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general-----
Santosh Rajan
http://santrajan.blogspot.com
|
|
Re: host-meta and "acct:"
You not *still* on the xrd.subject vs xrd.ietf.scopes conspiracy, are you?
Omitting xrd.subject just allows a security context/container to play its role. (The most rationale context is an https cert with domain-check assertion authenticating the https session over which one pulls the host-meta stream. Alternatively, per the standard, sign it per the XRD 1.0 spec and populate subject.)
I could see the case for requiring host-meta spec from IETF to disdclose HOW one would PROPERLY ppulate subekct, in the case that the XRD is signed. Why not make the case to the WG (else threaten them with raising the issue during WG and then IESG last call )
-----
Im obviously getting far too old for facebook. I didnt recognise the sound of the identity url you posted :-(. it's cute (in English)
Santosh Rajan wrote:
...
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.
...
--
http://hi.im/santosh...
|
|
Re: host-meta and "acct:"
Hehe Peter, as all stories go, Let us leave the inference and conclusions to the readers. On Tue, Oct 27, 2009 at 11:22 PM, Peter Williams <home_pw@...> wrote:
You not *still* on the xrd.subject vs xrd.ietf.scopes conspiracy, are you?
Omitting xrd.subject just allows a security context/container to play its
role. (The most rationale context is an https cert with domain-check
assertion authenticating the https session over which one pulls the
host-meta stream. Alternatively, per the standard, sign it per the XRD 1.0
spec and populate subject.)
I could see the case for requiring host-meta spec from IETF to disdclose HOW
one would PROPERLY ppulate subekct, in the case that the XRD is signed. Why
not make the case to the WG (else threaten them with raising the issue
during WG and then IESG last call )
-----
Im obviously getting far too old for facebook. I didnt recognise the sound
of the identity url you posted :-(. it's cute (in English)
Santosh Rajan wrote:
>
> ...
>
> 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.
> ...
> --
> http://hi.im/santosh
> ...
>
--
View this message in context: http://www.nabble.com/host-meta-and-%22acct%3A%22-tp26079872p26082181.html
-- http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: host-meta and "acct:"
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.txtIf 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@gmail.com
<acct%3Asantrajan@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@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general-----
Santosh Rajan
http://santrajan.blogspot.com
|
|
Re: host-meta and "acct:"
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.
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.txtIf 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@gmail.com
<acct%3Asantrajan@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@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general-----
Santosh Rajan
http://santrajan.blogspot.com
|
|
Re: 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@...> 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%3Asantrajan@...
>> < acct%253Asantrajan@...>" 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@...
>> http://lists.openid.net/mailman/listinfo/openid-general
>>
>>
>> -----
>>
>> Santosh Rajan
>> http://santrajan.blogspot.com
>>
>
>
--
-- http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: host-meta and "acct:"
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...]
Sent: Sunday, November 01, 2009 6:24 AM
To: Peter Williams
Cc: general@...
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@...>
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%3Asantrajan@...
>> <acct%253Asantrajan@...>"
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@...
>> 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
--
http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: 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@...> 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@...]
Sent: Sunday, November 01, 2009 6:24 AM
To: Peter Williams
Cc: general@...
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@...>
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%3Asantrajan@...
>> <acct%253Asantrajan@...>"
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@...
>> 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
--
http://hi.im/santosh
-- http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: host-meta and "acct:"
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...]
Sent: Sunday, November 01, 2009 7:41 AM
To: Peter Williams
Cc: general@...
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@...>
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@...]
Sent: Sunday, November 01, 2009 6:24 AM
To: Peter Williams
Cc: general@...
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@...> 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%3Asantrajan@...
>> <acct%253Asantrajan@...>"
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@...
>> 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
--
http://hi.im/santosh
--
http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: 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@...> 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@...]
Sent: Sunday, November 01, 2009 7:41 AM
To: Peter Williams
Cc: general@...
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@...>
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@...]
Sent: Sunday, November 01, 2009 6:24 AM
To: Peter Williams
Cc: general@...
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@...> 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%3Asantrajan@...
>> <acct%253Asantrajan@...>"
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@...
>> 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
--
http://hi.im/santosh
--
http://hi.im/santosh
-- http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: host-meta and "acct:"
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...]
Sent: Sunday, November 01, 2009 7:59 AM
To: Peter Williams
Cc: general@...
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@...>
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@...]
Sent: Sunday, November 01, 2009 7:41 AM
To: Peter Williams
Cc: general@...
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@...> 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@...]
Sent: Sunday, November 01, 2009 6:24 AM
To: Peter Williams
Cc: general@...
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@...> 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%3Asantrajan@...
>> <acct%253Asantrajan@...>"
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@...
>> 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
--
http://hi.im/santosh
--
http://hi.im/santosh
--
http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: host-meta and "acct:"
On Nov 1, 2009, at 8:13 AM, Peter Williams wrote:
> Yes. Only the XRD element has an xml:id attribute, schematically.
> But I
> could not detect your point, of saying this fact.
I imagine he was responding to your statement that:
> The subject has to bear the xml:id
XRD's extensibility model certainly allows you to put an xml:id on the
<Subject> if you want to, though that would certainly not be the
xml:id used as the <ds:Reference> in the signature. The Signature, if
present, MUST reference the xml:id attribute of the root XRD element
being signed. Keep in mind that this may or may not be the root
element of the XML document, as in the case of XRDS.
> And, a subject name is about an XRD in a context (in general). One
> such
> context is the native signing/trust model (if used).
I'm not completely sure what you mean here. The subject identifies
the resource the XRD is about, regardless of "context" (maybe
depending on how you define context?).
To maybe clear up some of the discussion around Subject, and whether
or not it is required (and hopefully not to re-open a can of worms
that has seemed to die down)... (and I realize I just sent some of
this in another thread on this list, but it's worth repeating)
An XRD Subject is effectively useful for two things.
1. It identifies the resource the XRD is about
2. It is anticipated that some XRD trust profiles will use the
subject URI to varying degrees to assess the trustworthiness of a
signed XRD. One example is by comparing the subject URI to key
material used to generate the signature. None of these XRD trust
profiles have been written yet, so no one can say with any certainty
exactly what they will contain. I CAN tell you that we have discussed
profiles that will most certainly make use of Subject, and we have
also discussed profiles that will very likely NOT make use of Subject.
Subject is not a required element of XRD. What it actually means for
an XRD to lack a Subject depends on a few things...
2. If the XRD is signed, then clearly it must be using a trust
profile that does not require a Subject. Remember, no XRD trust
profiles exist yet, but we do anticipate that there will be one or
more that won't require a Subject. That can't be said with any
certainty because we just don't know yet.
1. How do you know what resource an XRD is about if you don't have
a subject? As far as XRD proper is concerned, the answer is
undefined. XRD 1.0 gives you one way to identify the resource the XRD
is about, but says nothing about what it means if the Subject is
absent. This is intentional... we didn't want to preclude other ways
of identifying the subject (or maybe even subjects, plural) of the
XRD. What implication will these other subject-identifcation methods
have on applications and protocols that use XRD for resource
description? We can't really answer that, because we don't know. For
the use-cases we've been able to identify so far, and the ones we've
had in mind while designing XRD, it seems to work out okay.
It is entirely possible that some applications will require the
presence of an XRD Subject element, and that's perfectly okay. XRD
can be profiled to add whatever additional constraints a particular
application or protocol needs to be useful, secure, scalable, etc.
So what about XRDs that don't contain a Subject element, nor contain
any other defined way of identifying the resource(s) the XRD is
about? Again, this is undefined. If you're unable to identify (by
whatever means) the subject (explicit or implied) of the XRD, I can't
tell you what that means. It doesn't sound terribly useful. Would it
be a valid XRD? Yes, absolutely. Is it a useful XRD? No, probably
not, though someone may come up with a valid case for it. By the same
token, the following is also a completely valid XRD document:
<XRD xmlns=" http://docs.oasis-open.org/ns/xri/xrd-1.0" />
It's not useful at all, but it's entirely valid.
Try not to get too hung up on Subject. In many common use cases,
Subject will be present, and you won't have to worry about it. In
cases where Subject is not present, then there will need to be some
other defined means for providing the necessary information to address
common uses that Subject is used for. As long as you have some other
means to identify the resource the XRD is about and, if necessary, a
way to assess the trustworthiness of a signed XRD, then you can get by
just fine without a formal Subject element.
-will
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: host-meta and "acct:"
Why are you guys so stuck up on allowing XRD's with no Subject?
If you really want to do that, why don't you allow for an "Anonymous XRD" who's Subject is empty?
That is what the RDF folk did (its equivalent). Are you suggesting that you guys know something which those guys didn't know? (I had to reread the RDF spec to confirm this).
If that is the case why don't you clearly explain to everybody why the XRD need not have a Subject Element?
On Wed, Nov 4, 2009 at 1:54 PM, Will Norris <will@...> wrote:
On Nov 1, 2009, at 8:13 AM, Peter Williams wrote:
Yes. Only the XRD element has an xml:id attribute, schematically. But I
could not detect your point, of saying this fact.
The subject has to bear the xml:id
XRD's extensibility model certainly allows you to put an xml:id on the <Subject> if you want to, though that would certainly not be the xml:id used as the <ds:Reference> in the signature. The Signature, if present, MUST reference the xml:id attribute of the root XRD element being signed. Keep in mind that this may or may not be the root element of the XML document, as in the case of XRDS.
And, a subject name is about an XRD in a context (in general). One such
context is the native signing/trust model (if used).
I'm not completely sure what you mean here. The subject identifies the resource the XRD is about, regardless of "context" (maybe depending on how you define context?).
To maybe clear up some of the discussion around Subject, and whether or not it is required (and hopefully not to re-open a can of worms that has seemed to die down)... (and I realize I just sent some of this in another thread on this list, but it's worth repeating)
An XRD Subject is effectively useful for two things.
1. It identifies the resource the XRD is about
2. It is anticipated that some XRD trust profiles will use the subject URI to varying degrees to assess the trustworthiness of a signed XRD. One example is by comparing the subject URI to key material used to generate the signature. None of these XRD trust profiles have been written yet, so no one can say with any certainty exactly what they will contain. I CAN tell you that we have discussed profiles that will most certainly make use of Subject, and we have also discussed profiles that will very likely NOT make use of Subject.
Subject is not a required element of XRD. What it actually means for an XRD to lack a Subject depends on a few things...
2. If the XRD is signed, then clearly it must be using a trust profile that does not require a Subject. Remember, no XRD trust profiles exist yet, but we do anticipate that there will be one or more that won't require a Subject. That can't be said with any certainty because we just don't know yet.
1. How do you know what resource an XRD is about if you don't have a subject? As far as XRD proper is concerned, the answer is undefined. XRD 1.0 gives you one way to identify the resource the XRD is about, but says nothing about what it means if the Subject is absent. This is intentional... we didn't want to preclude other ways of identifying the subject (or maybe even subjects, plural) of the XRD. What implication will these other subject-identifcation methods have on applications and protocols that use XRD for resource description? We can't really answer that, because we don't know. For the use-cases we've been able to identify so far, and the ones we've had in mind while designing XRD, it seems to work out okay.
It is entirely possible that some applications will require the presence of an XRD Subject element, and that's perfectly okay. XRD can be profiled to add whatever additional constraints a particular application or protocol needs to be useful, secure, scalable, etc.
So what about XRDs that don't contain a Subject element, nor contain any other defined way of identifying the resource(s) the XRD is about? Again, this is undefined. If you're unable to identify (by whatever means) the subject (explicit or implied) of the XRD, I can't tell you what that means. It doesn't sound terribly useful. Would it be a valid XRD? Yes, absolutely. Is it a useful XRD? No, probably not, though someone may come up with a valid case for it. By the same token, the following is also a completely valid XRD document:
<XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0" />
It's not useful at all, but it's entirely valid.
Try not to get too hung up on Subject. In many common use cases, Subject will be present, and you won't have to worry about it. In cases where Subject is not present, then there will need to be some other defined means for providing the necessary information to address common uses that Subject is used for. As long as you have some other means to identify the resource the XRD is about and, if necessary, a way to assess the trustworthiness of a signed XRD, then you can get by just fine without a formal Subject element.
-will -- http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
 Re: host-meta and "acct:"
Maybe thats a problem with the XRD Spec you guys really need to reconsider. How long are you guys going to keep hiding behind such logic? On Wed, Nov 4, 2009 at 9:11 PM, Will Norris <will@...> wrote:
On Nov 4, 2009, at 7:28 AM, SitG Admin wrote:
If you really want to do that, why don't you allow for an "Anonymous XRD" who's Subject is empty?
Why require all XRD's to have a Subject field, if it can be empty? Can't it just be omitted entirely, saving bandwidth from transmitting an extra 19 (plus whitespace) bytes?
If it can be empty, it can be omitted - as I've said before, the lack of a field can implicitly be taken as the emptiness of a field.
Unless otherwise noted in this specification or particular profiles, all URIs in XRD documents MUST consist of at least one non-whitespace character.
-- http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: host-meta and "acct:"
We're not hiding anything. Non-whitespace characters are required to
make the meaning of a particular value unambiguous. Keep in mind that
the goal of making the <Subject> element optional is not to
necessarily allow for "Anonymous XRDs"... the goal is to allow the
subject of the XRD to be identified by means other than the <Subject>
element. I'm not completely sure what to make of an XRD that does not
identify its subject (by the <Subject> element or otherwise). There
may be a use case for it, but nothing immediately comes to mind.
-will
On Nov 4, 2009, at 7:45 AM, Santosh Rajan wrote:
> Maybe thats a problem with the XRD Spec you guys really need to
> reconsider.
>
> How long are you guys going to keep hiding behind such logic?
>
>
> On Wed, Nov 4, 2009 at 9:11 PM, Will Norris < will@...>
> wrote:
>
>>
>> On Nov 4, 2009, at 7:28 AM, SitG Admin wrote:
>>
>> If you really want to do that, why don't you allow for an
>> "Anonymous XRD"
>>>> who's Subject is empty?
>>>>
>>>
>>> Why require all XRD's to have a Subject field, if it can be empty?
>>> Can't
>>> it just be omitted entirely, saving bandwidth from transmitting an
>>> extra 19
>>> (plus whitespace) bytes?
>>>
>>> If it can be empty, it can be omitted - as I've said before, the
>>> lack of a
>>> field can implicitly be taken as the emptiness of a field.
>>>
>>
>>
>> you cannot have an empty subject. See section 1.5.2:
>>
>> Unless otherwise noted in this specification or particular
>> profiles, all
>>> URIs in XRD documents MUST consist of at least one non-whitespace
>>> character.
>>>
>>
>> -will
>> _______________________________________________
>> general mailing list
>> general@...
>> http://lists.openid.net/mailman/listinfo/openid-general>>
>
>
>
> --
> http://hi.im/santosh_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: host-meta and "acct:"
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Santosh
>
Why are you guys so stuck up on allowing XRD's with no Subject?
There is a web site with hundreds of *.html pages I wrote about football, dozens written by Alice about football, and a handful I wrote about politics.
My football pages all include <link rel=”describedby” href=”/jim.footy.xrd”/>.
Alice’s football pages all include <link rel=”describedby” href=”/alice.footy.xrd”/>.
My politics pages all include <link rel=”describedby” href=”/politics/meta/j.xrd”/>.
The content of /Jim.footy.xrd is
<XRD xmlns=…><Link><Rel>author</Rel><URI>http://jim.footyfanatics.fans/#me</URI></Link></XRD>
There is no <Subject> element. This is metadata for any resource that says this is its metadata, ie any resource with a “describedby” link pointing here.
There is no URI for that collections of resources that could be put in <Subject>.
I don’t need to go from metadata to resource, just from a resource to its metadata, so I don’t need <Subject> here.
James Manger
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: host-meta and "acct:"
Hi James, I can see a serious problem with your argument. You are assuming the meta-data "is not a resource". I think meta-data is also a "Resource".
Can you tell me why "meta-data" is not a Resource?
All the three XRD's you mentioned are also "Resources", and they also have <Subjects> that happen to be the very URI's that you use to address them. eg,
On Thu, Nov 5, 2009 at 7:13 AM, Manger, James H <James.H.Manger@...> wrote:
Santosh
>
Why are you guys so stuck up on allowing XRD's with no Subject?
There is a web site with hundreds of *.html pages I wrote about football, dozens written by Alice about football, and a handful I wrote about politics.
My football pages all include <link rel=”describedby” href=”/jim.footy.xrd”/>.
Alice’s football pages all include <link rel=”describedby” href=”/alice.footy.xrd”/>.
My politics pages all include <link rel=”describedby” href=”/politics/meta/j.xrd”/>.
The content of /Jim.footy.xrd is
<XRD xmlns=…><Link><Rel>author</Rel><URI>http://jim.footyfanatics.fans/#me</URI></Link></XRD>
There is no <Subject> element. This is metadata for any resource that says this is its metadata, ie any resource with a “describedby” link pointing here.
There is no URI for that collections of resources that could be put in <Subject>.
I don’t need to go from metadata to resource, just from a resource to its metadata, so I don’t need <Subject> here.
James Manger
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
-- http://hi.im/santosh
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: host-meta and "acct:"
So we have two competing ideas about what it means for an XRD to not
identify the resource it is about. James suggests that it is whatever
resource points to the XRD and claims that the XRD is its descriptor.
James.H.Manger@...> wrote:
> <XRD xmlns=…><Link><Rel>author</Rel><URI>http://
> jim.footyfanatics.fans/#me
> </URI></Link></XRD>
>
> There is no <Subject> element. This is metadata for any resource
> that says
> this is its metadata, ie any resource with a “describedby” link
> pointing
> here. There is no URI for that collections of resources that could
> be put in
> <Subject>.
Alternately, Santosh suggests that it is the XRD resource itself.
On Nov 5, 2009, at 7:43 AM, Santosh Rajan wrote:
> All the three XRD's you mentioned are also "Resources", and they
> also have
> <Subjects> that happen to be the very URI's that you use to address
> them.
> eg,
> <Subject> http://mywebsite/jim.footy.xrd</Subject>
The correct answer is that the subject is undefined. So both of the
above answers are wrong, but they both COULD be right. There are only
two defined ways today for an XRD to identify the resource(s) it is
describing. Those are the <Subject> element defined in the XRD spec,
and whatever element Host Meta ends up defining. Aside from those
two, nothing more has been defined. There is no implicit subject
according to the XRD spec.
If an application or protocol wants to define some other mechanism to
identify the resource an XRD is about in the absence of a <Subject>
element, they are free to do so. In fact, they are encouraged to so.
We left it undefined intentionally because there is no one right
answer... it depends on your application, your security and trust
requirements, and any number of other factors.
-will
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
|
Re: host-meta and "acct:"
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi Santosh,
> You are assuming the meta-data "is not a resource".
No I am not.
> I think meta-data is also a "Resource".
I agree, the jim.footy.xrd file has its own URI so it is a resource — but that is irrelevant to <Subject>.
The XRD <Subject> element “provides the identifier of the resource
described by this XRD” [XRD v1.0 WD9, §2.1.1.].
jim.footy.xrd does not describe itself, it describes hundreds of other *.html pages I wrote about football. It makes no sense for <Subject> to hold the URI
of the XRD file itself in this situation.
If you have an OpenID identifier that isn’t used for anything else (eg its not your blog or home page), then (in some potential future OpenID v3) a GET on
that OpenID identifier could return a XRD with its own URI in the <Subject>. It would be metadata about itself. It could point to an OP directly, eliminating the extra round-trip of going from a resource to its metadata since they are one and the same in this
case. [Mind you, I’m not sure you gain much over serving an HTML page with OpenID v1 or v2 <link>s to the OP.]
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general
|
