[IETF-IDRM] Fwd: Re: [IDRM] draft-irtf-idrm-handle-system-00.txt
Thomas Hardjono
thardjono@mediaone.net
Wed, 23 May 2001 14:33:34 -0400
>Date: Wed, 23 May 2001 10:00:13 -0400
>From: Michael Mealling <michael@neonym.net>
>Subject: Re: [IDRM] draft-irtf-idrm-handle-system-00.txt
>To: Mark Baugher <mbaugher@cisco.com>
>Cc: Michael Mealling <michael@neonym.net>, ietf-idrm@lists.elistx.com,
> ssun@cnri.reston.va.us, llannom@cnri.reston.va.us
>Reply-to: Michael Mealling <michael@neonym.net>
>User-Agent: Mutt/1.1.2i
>List-Owner: <mailto:ietf-idrm-help@lists.elistx.com>
>List-Post: <mailto:ietf-idrm@lists.elistx.com>
>List-Subscribe: <mailto:ietf-idrm-request@lists.elistx.com?body=subscribe>
>List-Unsubscribe: <mailto:ietf-idrm-request@lists.elistx.com?body=unsubscribe>
>List-Archive: <http://lists.elistx.com/archives/ietf-idrm>
>List-Help: <http://lists.elistx.com/elists/admin_email.shtml>,
> <mailto:ietf-idrm-request@lists.elistx.com?body=help>
>
>On Tue, May 22, 2001 at 11:21:48PM -0700, Mark Baugher wrote:
> > At 01:31 AM 5/23/2001 -0400, Michael Mealling wrote:
> > >On Tue, May 22, 2001 at 10:26:05PM -0700, Mark Baugher wrote:
> > > > My first comment is that there does not seem to be name-resolution
> > > draft in
> > > > the mix. Is this not to be published? I can see a lot of uses for a
> > > > namespace that is not global, such as between a content provider
> > > > (publisher) and service provider (distributor) that want to use the
> > > > metadata facilities of handles to store rights information with the
> > > content
> > > > work and to identify one or more "official repositories" for the
> content
> > > > work. If you're requiring a global namespace but not publishing the
> > > > resolution mechanisms, then this seems to be an impediment to many
> > > > business-to-business uses.
> > >
> > >If you need name resolution then you should take a look at the
> > >URI Resolution documents:
> > >http://www.ietf.org/internet-drafts/draft-ietf-urn-uri-res-ddds-03.txt
> > >http://www.ietf.org/internet-drafts/draft-ietf-urn-dns-ddds-database-04
> .txt
> > >http://www.ietf.org/internet-drafts/draft-ietf-urn-ddds-04.txt
> >
> > As 5.3 of the draft concludes, the success of either urn or the Handle
> > System do not depend on each other. I did not glean from the Handle
> > System Overview I-D the idea that the Handle System would use
> > URN resolvers.
>
>Right. I'm suggesting that instead of sticking to one URI scheme (handles)
>that DRM should work for all URIs. And in the case where DRM needs
>persistence it should only go as far as requiring URNs.
>
> > I guess we should ask Sam and Larry about that.
>
>I was at a meeting with them last year about this very subject and at least
>the intent at that time was to register handles as a URN namespace. I haven't
>heard whether that intent has changed but I also haven't seen the NID
>registration document go by...
>
> > >Is there any reason why a DRM system needs a special namespace? I've
> > >heard a persistence requirement from some and in that case you could
> easily
> > >use URNs. But in the general case, shouldn't a URI be sufficient for
> > >identifying the resource that is having its rights digitally managed?
> >
> > I really don't know if persistent naming is a requirement for DRM on the
> > Internet.
>
>I haven't seen a compelling need for it either...
>
> > One issue that people have is that it is difficult or not impossible to
> > identify content works and uses of content works that are legitimate
> > from those that are not.
>
>And the desire is to be able to tell that from the identifier? That's really
>dangerous ground becuase items and their identifiers change. Building human
>semantic hints into the identifier for an object makes that identifier
>much more fragile. That is the number one reason why there is that silly '//'
>in all http URIs.
>
> > One idea we have been discussing in the group is the need for an
> > infrastructure that identifies legitimate repositories and legitimate
> > uses of content works - or of any information assets to include
> > the case of personal information that is used for the purposes of
> > authentication.
>
>Sure. That's one of the intended functions of the URI Resolution process:
>take an identifier and tell me who is authoritative for it and allow me
>to ask them various questions via various protocols in order to do various
>things...
>
> > The Handle System is one system that addresses
> > these requirements for content-work publishing, in my opinion. You
> > don't get this with URIs today.
>
>By themselves? No. That's not what they're intended to do. URIs just
>identify. Its the systems that provide access to that object and emerging
>metadata systems (like RESCAP and RDF) that tell you things about the
>object prior to accessing it.
>
> > Will publishers, record labels, movie studios want the namespace and
> > persistence features as well? I don't know.
>
>Apparently they do because handles inherit the persistence requirements
>of URNs (mainly because at one point handles were URNs since Bill Arms
>was part of the entire URN discussions from the beginning and URN
>resolution framework was engineered to accomodate the handle system).
>
> > > From all of the examples I've ever seen any DRM system is really just
> > >a special function metadata service with some strong encryption thrown
> > >in for good measure....
> >
> > There needs to be integrity checking and authentication of the information
> > asset and its source.
>
>Sure. But that's a feature of the system you use to get access to the object
>in question. It isn't really a feature of the metadata store that tells you
>things about it (the metadata store better be able to tell you the things
>you need to know to do that integrity checking but doing the integrity
>checking itself is feature overloading).
>
> > If the work is encrypted, then this entails some
> > authentication of the entity that's going to receive the key. Many people
> > would include clearing systems as part of DRM.
>
>Ok. I guess I lump that under the access method. I guess what I'm getting
>at is that there needs to be a more modular approach where by someone
>can pick and choose what DRM components they need instead of having
>to swallow the 'whole enchilada'. Then each of those components should
>use as much existing technology as possible:
>
>1) resource identification -- should be just URIs in general. If an object
>uses a DRM system then that's discovered during resolution...
>
>2) secure rights metadata service -- should be something a little more
>open than the handle system. The stuff that the RESCAP working group is
>working on could be a very good candidate. At the same time you probably
>don't want to tie it to any particular protocol (lots of folks will want
>to use SOAP).
>
>3) access control -- new DRM type services for accessing objects securely and
>in a way that enforced the rights that are expressed in #2.
>
>-MM
>
>--
>--------------------------------------------------------------------------------
>Michael Mealling | Vote Libertarian! | urn:pin:1
>michael@neonym.net | | http://www.neonym.net
> | | go:Michael Mealling