[IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt

[Mark Baugher]

Michael,

At 10:00 AM 5/23/2001 -0400, Michael Mealling wrote:


>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 agree and I don't think it's being debated whether multiple schemes will
will supported for DRM.  The Handle System has a number of interesting 
properties
in addition to persistent naming such as associating rights metadata and a 
trust
infrastructure with a content work.  That's why it's being discussed on 
this list.
I think that CNRI wants to publish these drafts as Informational Standards 
and this
discussion hopefully will help the authors improve them through this process.

<snip>

> > 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.

As I said above, there's more to the Handle System than the naming.

<snip>


> > 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).

Hence the relevance to this list.


> > > 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).

The metadata needs authentication and integrity.  There also needs to be
information about any object to identify how the infrastructure to be
used for authentication and integrity.


> > 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:

Is the Handle System purely a vertical solution?  If so, then why would the
authors unbundle the protocol, naming, and service definitions in separate
I-D's?


>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).

Right now, there are many candidates for the service, specification, trust,
and authorization.  Since we are a Research Group and do not develop
standards, all of these candidates are of interest to us.


>3) access control -- new DRM type services for accessing objects securely and
>in a way that enforced the rights that are expressed in #2.

I'd call this "authorization" rather than access control.  A rights-managed 
object
has a finer-grained access at the level of individual rights.

Mark


>-MM
>
>--
>--------------------------------------------------------------------------------
>Michael Mealling        |      Vote Libertarian!       | urn:pin:1
>michael@neonym.net      |                              | http://www.neonym.net
>                         |                              | go:Michael Mealling