W3C home > Mailing lists > Public > uri@w3.org > July 1995

URN Resolution Security and Privacy Issues (fwd)

From: Pierre Landau <pierre@indirect.com>
Date: Mon, 10 Jul 1995 12:18:32 -0700 (MST)
Message-Id: <199507101918.MAA15589@bud.indirect.com>
To: uri@bunyip.com
> From: Fisher Mark <FisherM@is3.indy.tce.com>
> To: "'URI'" <uri@bunyip.com>
> Subject: URN Resolution Security and Privacy Issues
> Date: Mon, 10 Jul 95 11:41:00 PDT
> Message-Id: <30017541@MSMAIL.INDY.TCE.COM>
> Encoding: 29 TEXT
> X-Mailer: Microsoft Mail V3.0
> Sender: owner-uri@bunyip.com
> Precedence: bulk
> Because the mere knowledge that a string is a valid URN can useful in some 
> contexts, it is advisable to have mechanisms that prevent the discovery of 
> this fact.  Any generally useful resolution service must be able to not only 
> refuse to resolve a URN (or URL), it must be able to avoid giving the 
> impression that what was handed to it was a valid URN or URL to begin with. 

Maybe I'm missing something here.  My understanding of the motivation 
behind the creation of a URN was to say "I'm now publishing something I 
want people to read/use/whatever; here's a persistent name for that object."
Any URN registry service must be able to answer the question of whether a 
URN exists in order to decide whether it can be assigned to a new object.
If you're playing with confidential information, what is it doing on an 
essentially public network, where security is basically nonexistent?
Received on Monday, 10 July 1995 15:18:24 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:31 UTC