OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xri] Designating DNS discovery for non-HTTP URIs


I have been thinking about this issue of using DNS for a DNS authority based scheme to delegate responsibility for mapping meta-data about its resources.

I feel torn between the practical issues of just doing it in a way that people will be able to use most easily, and the overall design principal of authority hierarchy in URIs. 

I agree with some that probably the worst consequence is setting a bad example for others.

If I step back a bit and ask the question is DNS the only way a organization can assert it's authority outside of a scheme,  it struck me that perhaps there is another way that sidesteps the DNS issue.

A signing cert from Verisign etc states that you have control over a domain.  Not a URI not a particular scheme like https: for that host or domain, but the domain itself.

Given the relative insecurity of DNS (leaving dnssec aside for this conversation)  I would rather trust site-meta if it has been signed by the domain cert indicating it is authoritative for mailto and or xmpp rather than looking to DNS.

I think if site-meta is signed by the cert of the domain then we maintain the authority chain though PKI rather than resolution.
I am OK with that.  (Mark please speak up if you find this an awful principal)

So all schemes SHOULD check the detached sig for site meta, and site-meta is considered authoritative for all the schemes it has maps for as long as the authority segment of the scheme matches the CN of the cert.  (Yes we may need to include subjectAltNames where the value is a DNS name or some other matching rule)

An alternative though weaker option for the RP is to retrieve the site-meta over https:.  That however is much weaker as an attacker replacing a single text file on a site is a much easier thing to do than getting the private key for a site to generate the sig.

It would be up to the needs of the RP software to choose the appropriate security.

If we did something like that I could be persuaded to drop the DNS check from your proposal.

Peters DNS resolution proposal is a separate issue.  


On 9-Jan-09, at 8:56 PM, Eran Hammer-Lahav wrote:

I am happy to adjust it to “some hesitation”... :-)

I added a new section to my draft last night explaining the reasons for this DNS workaround. I decided to promote a position I am still not fully sold on as a way to solicit feedback. I am actually hoping everyone will ask to drop it, but at least it is explicitly acknowledged as something people have expressed reservations for.


On 1/9/09 3:33 PM, "David Orchard" <orchard@pacificspirit.com> wrote:

(note, my response will not make it onto the XRI list, hopefully JohnB will forward it).

Usually () in TAG minutes indicate side comments that generally are informative and to be captured but not formal.  It's interesting that Dan did not want to make his comment formally.  And if you interpret his comment formally, I wonder if adding DNS doesn't solve his concern.  

I'm not convinced that the TAG comments can be called "strong resistance".  Frankly, I'd give another couple kicks at the can before adding such a complex optional feature.  I do appreciate your sensitivity to pushback and trying to ensure a smooth passage.


On Fri, Jan 9, 2009 at 3:01 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
From: http://www.w3.org/2001/tag/2008/12/10-minutes

DO: I think the TAG could talk about the issue with Authority. Eran has asked me and Jonthan to think about whether the TAG has anything to say about whether a file like this can speak >authoritatively< for, e.g. a mailto: URI.

<ht> HT acknowledges that his suggestion has a huge problem in the legacy/name squatting

<Zakim> skw2, you wanted to suggest that jar also mention the metadata-discovery googlegroup

JR: Don't think I want to.

SW: Should we point out the Google Group?

<DanC_lap> (if you want to speak authoritatively for a mailto: URI, you have to be the SMTP server. or edit the SMTP standard)


From: http://lists.w3.org/Archives/Public/www-talk/2008NovDec/0012.html

From: Mark Nottingham <mnot@mnot.net <http://mnot@mnot.net> >
Date: Wed, 3 Dec 2008 11:24:04 +1100


/site-meta on http://foobar.com/ doesn't (and can't, on its own) make  
any authoritative assertions about mailto:dirk@foobar.com; even though  
the authority is the same, the URI scheme is different.

I know this particular issue is an important one to the OpenID folks,  
but there needs to be a very careful and broad discussion of allowing  
policy and metadata from HTTP to be considered *automatically*  
authoritative for other protocols.


So there seems to be some resistance to the idea that an HTTP server will be used as the generic provider of discovery information for non-HTTP resources. That is what this whole DNS proposal is about. Personally, I think the "lack of authority" argument is not very interesting, and that it is up to applications to decide if they want to accept what an HTTP server has to say about a non-HTTP URI. But I rather include something like this and make the discovery flow completely generic across URI scheme, than limit it to HTTP/S URIs only.


On 1/9/09 1:27 PM, "David Orchard" <orchard@pacificspirit.com <http://orchard@pacificspirit.com> > wrote:

On Thu, Jan 8, 2009 at 5:17 AM, Peter Davis <peter.davis@neustar.biz <http://peter.davis@neustar.biz> > wrote:
On Jan 7, 2009, at 6:40 PM, Eran Hammer-Lahav wrote:

There seems to be strong resistance in various communities to the idea that
an HTTP server can speak authoritatively for non-HTTP URIs. There is also
strong resistance to using DNS as the entry point for resource discovery. At
the same time, it is clear we need to support non-HTTP URIs and there is
strong desire to include a DNS flavor.

Can you provide any references to where this resistance is occurring?

I would also like to see references for such resistance.  I think as soon you as you go from HTTP to HTTP + DNS, people are rightfully going to start asking about their favourite protocol, such as XMPP, BEEP, WS-*, SIP, etc.

I think there needs to be compelling evidence to support such a complication.  Every thing we can possibly remove from V1 only helps achieve interoperability by reducing features, especially optional ones.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]