Eran,
I hope at some point openID will change to use the subject/cannonicalID of the XRD as the claimed_id for URI as well as XRI.
I don't have a problem with having URI x expressing a about link relationship to a XRD with a subject y.
I think that people will want to do that with blogs and other resources that are about them.
For security reasons you do need to verify the subject/cannonicalID but I don't see a way to easily avoid that except in the case the subject was one of the URI in the redirect chain you followed as part of discovery.
I think trying to unwind the tangle of http response codes is almost hopeless.
My opinion is that any URI should be able to express a relationship via a link header and it up to the application doing the discovery to decide if it wants to retrieve one or all of the XRD.
Perhaps we need XRDS for URI so that you can show the path through the HTTP redirect chain and all of the XRD discoverd as part of that process.
That was a joke Drummond:)
=jbradley
On 4-Feb-09, at 1:42 PM, Eran Hammer-Lahav wrote: Hopefully, the increasing complexities of the HTTP approach will stay confined to the debate and will be resolve in the spec. But either way, the DNS approach does not solve anything. You still have the same issue of the undefined relationship between a 'resource' and 'URI', and the semantic meaning of HTTP response code as they apply to their representation. Consider OpenID. You still have to follow redirects and figure out your claimed identifier, even if when you find it, you use DNS and not link headers... EHL -----Original Message-----
From: Peter Davis [mailto:peter.davis@neustar.biz]
Sent: Wednesday, February 04, 2009 5:41 AM
To: Eran Hammer-Lahav
Cc: Drummond Reed; 'XRI TC'
Subject: Re: [xri] Context URI (was RE: [xri] Minutes: XRI TC Telecon
8-9AM PT Tue 2009/02/03)
I have to say that the increasing complexities of redirects and the
varied manifestations of the Link property make the DNS approach even
more desirable for my implementations. Setting aside folks lack of
familiarity of NAPTR RRs, the rest is pretty trivial to implement.
It would also allow for provide host-meta for hosts which are not HTTP
hosts (say, mail hosts/relays for example, who might want to advertise
relay policies instead of HTTP services)
food for thought, but then, of course, I am a tad biased :-P
=peterd
On Feb 4, 2009, at 1:53 AM, Eran Hammer-Lahav wrote:
Sure.
The trick is to use it but not really define it... other then it is
the 'subject' of the link relation. In a way, this flips the
semantics. Instead of talking about a resource that has a URI, we
are talking about a URI that (when dereferenced and accessed) has a
resource representation.
There are so many pitfalls in this that I spent the whole day
writing text only to erase it each time, with the conclusion that it
really cannot be directly addressed.
Few examples:
The spec (-01) says to follow redirects on Link header/element. This
of course breaks its compatibility with host-meta (new name for site-
meta) because the template in host-meta cannot express redirections.
It goes directly to the descriptor.
Turning it around, that is, telling the client to first follow
redirects (i.e. try to HEAD the resource), find the context URI,
then look for links there (or use the template on it), breaks it
too, because now the benefit of host-meta not requiring any resource
interaction is gone.
The only thing the spec can do (it seems) is to perform URI
discovery, that is, finding a descriptor that is linked to a
specific URI, no redirects etc. If that descriptor is not suitable,
a new context URI has to be found. Only, URI discovery is a bad term
because the descriptor is for a resource, not a URI...
Then again, host-meta loses the added value of knowing the HTTP
response code of the resource it is attached to, which in all of
these examples, means something for the discovery itself. That's bad
because the HTTP response code cannot be part of this. It is too
specific to HTTP, to semantic meanings of response codes, to the
subjective definition of a representation (and what constitutes one).
So I don't think we will end up with a new useful and well defined
term. Seems 'context URI' is like porn. I can't define it but I know
it when I see it.
EHL
-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Tuesday, February 03, 2009 10:34 PM
To: 'XRI TC'
Subject: [xri] Context URI (was RE: [xri] Minutes: XRI TC Telecon
8-9AM
PT Tue 2009/02/03)
Sorry to miss the meeting today (Brian, thanks for keeping
minutes). I
am
very interested in this concept of a Context URI. It could address a
number
of longstanding issues. Eran, can we put it on the agenda for
Thursday?
=Drummond
-----Original Message-----
From: Brian Eaton [mailto:beaton@google.com]
Sent: Tuesday, February 03, 2009 9:07 AM
To: XRI TC
Subject: [xri] Minutes: XRI TC Telecon 8-9AM PT Tue 2009/02/03
Following are the minutes of the unofficial telecon of the XRI TC
at:
Date: Tuesday, 3 February 2009 USA
Time: 8:00AM - 9:00AM Pacific Time (16:00-17:00 UTC)
ATTENDING (may be incomplete, scribe was incompetent).
Peter Davis
Breno de Medeiros
Eran Hammer-Lahav
John Bradley
Brian Eaton
AGENDA
Note that the agenda for Tuesday calls is now on the Self-Service
Agenda
page:
http://wiki.oasis-open.org/xri/SelfServeAgenda
The agenda items below are listed on that page with dated/numbered
headings.
Meeting minutes, XRI TC Tuesday, Feb 3
------ Resource descriptor discovery
Eran working on rewriting spec to figure out handling of 3xx and
4xx
return codes.
New concept: context URI.
For a browser: the page being displayed.
For a semantic web app: might be anything, maybe 303 is relevant,
maybe
not.
For OpenID: starts with claimed ID, follows redirects, then
performs
discovery on final URL.
Problem exists if you get a 302 and a Link header. What if the
resource returns a 302, but I'm interested in the original URL, not
the destination of the redirect?
Another example: just because a resource returns a 401 doesn't mean
that you didn't discover useful information. A 401 with a Link
header
could be really useful.
Context URI could be defined as "the resource URI that is relevant
to
the application".
OpenID (and other usages) of Link header will need to define the
context URI, this will have to be carefully profiled. There is
some
disagreement about how this is defined in OpenID today, but
everyone
agrees the spec is open to multiple interpretations.
------ Status of site/hostmeta.
New draft coming out in the next day or two.
New file name: hostmeta
New format: flat file, one entry per line. Base spec will define
Link
field. Discovery will add an additional field.
Registration authority will exist for new fields.
------ Simple XML DSig
Clarification: we are signing the serialized XML document, not XML
doc
plus metadata.
Example: to generate the signature you would need to open a file
and
read in the raw bytes of the file. You could also base64 encode
the
raw octet stream and embed it in an XRDS to get back the raw octet
stream.
Why not sign the base64 encoding? Because not everybody base64's
the
same way. Some software adds line breaks, other doesn't.
What about CR LF conversion in operating systems? Some software
will
screw up text files by tampering with line feed characters. We are
OK
with people suffering as they figure out how read files as binary.
Every modern OS has this capability, it's necessary for image
processing/multibyte character streams.
Signature bytes are not included in the file, but all signature
metadata
is.
Any security implications if doc is not served over https? You
don't
get privacy without https. You still have integrity checks.
Integrity checks based on X.509 certificates and prayer.
Should we include support for PGP/other key types?
Cons: no support in libraries.
Cons: nobody expects anything but X.509 to work.
Pros: if we don't need to forbid it, why should we?
We do have support for self-signed certs, no mention of trust
hierarchy. People are free to innovate.
How much can we reuse XML DSIG code?
Potentially some reuse of the XML parsing code, not anything else.
Very little code needed to implement simple sign (under 400 lines
of
java.)
Peter will notify SSTC about xml dsig simple sign. It's bad to
have
multiple simple sign algorithms floating around.
------ Trust model
Eran asks Brian what he thinks of Subject at Link level.
Brian doesn't want to argue about trust in the abstract, too hard
to
pin down use cases. Google is looking at how OpenID trust will
interact with trusted XRD discovery.
Eran does see a need for generic XRI discovery trust.
John thinks that we need to figure out the claimed ID before we can
figure out trust. (Amen!)
------ HTML discovery
Eran wants to forbid accepting Link elements outside of <head> in
HTML, or appropriate place in ATOM.
Eran is not sure whether we can make people accept that limitation.
Most OpenID libraries just use regular expressions.
If we restrict discovery mechanisms we lock out users who don't
have
access to the <head> of their own pages.
There is a need for a priority order in discovery, so that all
discovery approaches produce the same descriptor.
Eran's proposed requirement: no matter which approach the client
uses,
it always gets the same descriptor set.
John's proposed requirement: sites should try to make sure that is
true, but in the real world there will sometimes be
inconsistencies.
If we get restrictive about discovery, blog hosting providers will
need to provide users good tools to help them be compatible with
discovery.
-------------------------------------------------------------------
--
To unsubscribe from this mail list, you must leave the OASIS TC
that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-
open.org/apps/org/workgroup/portal/my_workgroups.php
--------------------------------------------------------------------
-
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/
my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-
open.org/apps/org/workgroup/portal/my_workgroups.php
Peter Davis: NeuStar, Inc.
Director & Distinguished Member of the Technical Staff
45980 Center Oak Plaza Sterling, VA 20166
[T] +1 571 434 5516 [E] peter.davis@neustar.biz [W]
http://www.neustar.biz/
[X] xri://@neustar*pdavis [X] xri://=peterd
The information contained in this e-mail message is intended only for
the use of the recipient(s) named above and may contain confidential
and/or privileged information. If you are not the intended recipient
you have received this e-mail message in error and any review,
dissemination, distribution, or copying of this message is strictly
prohibited. If you have received this communication in error, please
notify us immediately and delete the original message.
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|