[IETF-IDRM] Re: [IDRM] DRM Taxonomy work -- drm framework... -- handle system

[Sam X. Sun (@S2000)]

Hi Michael,

I agree with you that DRM doesn't have to stick with any specific technology
for its process. All we wanted here is to understand the process, and
identify technologies that can be applied to it...

In terms of Handle System and URN, I would say that they are quite different
now in terms of how they work and the issues that they want to address.
Handle system started about the same time PURL and URN started, trying to
address persistence issue of URL namespace. But later we found that
persistence is more of a social and/or management issue than a mere
technical one. While Handle System does provide a technical approach to
encourage more persistent namespace management, we have put more focus on
service security, distributed name administration, internationalization
(i18n), and service scalability. It might be helpful if you can read the
latest HS drafts to understand the difference... On the other hand, I see no
reason why Handle System cannot work with URN. One way to do it is to
register HS namespace as a namespace under URN, as we discussed earlier last
year. The issues that we need to address are how to make sure that the NAPTR
approach won't become a bottleneck, and how to achieve service security over
such approach. Maybe we should discuss these in a separate thread, or bring
them to the URN working group...

Regarding URI and HS, I'm not sure if they are comparable. I tend to think
that URI is a collection of name services, and Handle System is just a
specific one, under a specific protocol. While some members of URI can be as
secure as you want, others can be totally insecure. I wonder if it's
appropriate to say a URI in general is secure, or carries any semantic
meaning (a name, an address, an identifier, etc)? In fact, because DNS is
not secure as we know of today, that makes any name service based on DNS
questionable in their security. The Handle System is designed to be
independent of DNS, and to address the security and i18n issues that DNS is
struggling to overcome. It has the advantage that it's starting from
scratch, and doesn't have to deal with the backward compatibility issues
that DNS has to take care of... On the other hand, we are in the process of
defining handle system URI syntax for handles to be used in web context. In
that sense, Handle system defines a namespace under URI, and we are in
agreement there.

In fact, I'm more inclined to think that Handle System is in par with DNS.
In fact, if DNS can address security, i18n, access control on name
attributes, and to allow individuals to manage the names they registered, we
probably won't need the Handle System. On the other hand, people from DNS
working group has refused to apply DNS as a general name service other than
network-address translation, which makes us think that an independent name
service would be helpful...


Cheers,
Sam

----- Original Message -----
From: "Michael Mealling" <michael@neonym.net>
To: "Sam X. Sun (@S2000)" <ssun@cnri.reston.va.us>
Cc: "Mark Baugher" <mbaugher@cisco.com>; <ietf-idrm@lists.elistx.com>
Sent: Wednesday, May 23, 2001 10:10 AM
Subject: Re: [IDRM] DRM Taxonomy work -- drm framework...


> Hi Sam!
>
> On Wed, May 23, 2001 at 02:03:48AM -0400, Sam X. Sun (@S2000) wrote:
> > Regarding the handle system, I think there are two sides of DRM that
could
> > take advantage of it. First is the metadata and content attribute
> > association, as you mentioned in the DOI application.
>
> >From what I remember this part of the handle service seemed easily
> seperable from the resolution part of the system. The query methods
> for the attribute value pairs were straight forward and secure but really
> weren't tied to how resolution happened, right?
>
> > The other is the
> > identity reference for "content holder" (e.g. consumer identity).
>
> I.e. you assign some identifier to the entities involved in the
transaction?
>
> > What makes handle system unique in this case is that it provides a
secured
> > name resolution service (for name attribute binding),
>
> I wouldn't say that the handle system is unique in that regard. The entire
> URI Resoluion process was built to be as secured as you wanted it to be.
> Heck, since Bill built the handle resolution system to mirror the URN
> resolution mechanism they're pretty much identical.
>
> > , and allows ownership to be
> > defined per name (vs. URL, where the name administration belongs to the
site
> > manager). This is particularly important for individuals to be able to
> > manage their identity attributes, including their public keys.
>
> Can you explain that one further? Are you suggesting that URIs that
> have domain-names somehow confer ownership semantics? We should be
> very clear here since whether or not a URI is a name has everything to do
> with how you actually use it and nothing to do with what it actually looks
> like...
>
> > The point I was trying to make in my earlier message is that we probably
> > need to pay equal attention for identity or trust management as we do
for
> > content management. And I want to understand better the nature of the
> > identity used in DRM application before we move further into the
framework.
>
> Same here. As yet I can't see a reason that URIs are no sufficient. You
> have a requirement to identifiy all parties in the transaction but
> that just means you assign a URI to the parties involved as well...
>
> -MM
>
> --
> --------------------------------------------------------------------------
------
> Michael Mealling |      Vote Libertarian!       | urn:pin:1
> michael@neonym.net      |                              |
http://www.neonym.net
>                         |                              | go:Michael
Mealling