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

[Michael Mealling]

On Wed, May 23, 2001 at 01:10:19PM -0400, Sam X. Sun (@S2000) wrote:
> 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...

Great! There's alot of stuff like this being handled in the RDF/Semantic Web
areas in the W3C so that's one place we really should be watching since
it'd be a shame for the IETF and the W3C to diverge here....

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

Sure. From what Larry was talking about, the system is much more concerned
about the rights metadata than the identifier resolution process...

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

Agreed. But that doesn't negate the fact that if you know the identifier
is supposed to be persistent you can make a lot of safe assumptions...

> While Handle System does provide a technical approach to
> encourage more persistent namespace management, we have put more focus on
> service security, 

Which is one thing this group will really need...

> distributed name administration, 

What's being adminstered? Is that for provisioning of the identifier or managing
the metadata associated with the object being identified? The first is
interesting (and actually what the PROVREG group is doing.) The second
is a metadata service feature....

> internationalization
> (i18n), and service scalability. It might be helpful if you can read the
> latest HS drafts to understand the difference... 

I'll go check 'em out. Has it changed that radically?

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

That should be fairly painless. I'll send you the template....

> The issues that we need to address are how to make sure that the NAPTR
> approach won't become a bottleneck, 

It really can't. You only do one lookp and the record has a time to live of
several _years_. From my analysis you end up doing the _exact_ same number of 
lookups for NAPTR records in the  degenerative case (which handles would be)
as you do for A records....

> and how to achieve service security over such approach. 

The same way you are now. URI resolution just gets you to the authoritative
server for that identifier. How secure it is after that point is up to you and
the types of protocols/services you require to do the task.

> Maybe we should discuss these in a separate thread, or bring
> them to the URN working group...

I think that would be best. We don't want to bug these guys with identifier
stuff to much. ;-)

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

Semi-right. A URI is an identifier, nothing else. Some identifiers have
_default_ methods for resolving into a representation of the abstract 
object they identifier but there is no requirement that it be the only method.

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

Correct. URIs themselves say nothing about security since they're just
identifiers. Its how you use them that ends up being secure or not secure.
I.e. if I use an http URI in some service where every single entity is
signed and encrypted then I'm using that URI securely. The URI itself
doesn't create or require security....

> In fact, because DNS is
> not secure as we know of today, that makes any name service based on DNS
> questionable in their security. 

Not true. While some aspects of DNSSEC are still being worked on. It is
very possible to have trusted DNS in normal operation. 

> The Handle System is designed to be
> independent of DNS, and to address the security and i18n issues that DNS is
> struggling to overcome. 

And the URI resolution mechanism I mentioned solve those problems as well.
(Besides, i18n issues aren't really identifier related issues anyway.)

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

Not really. My suggestion is that any DRM shouldn't need to make requirements
about the identifier itself. Any URI should be able to be used to find out
about and get rights enabled access to any object. Digital Rights
Management has about zero to do with the identifier used to talk about
the object....

> In fact, I'm more inclined to think that Handle System is in par with DNS.

I'm more inclined to think of the RESCAP Working Group actually. 

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

With the exception of that last item, this is _exactly_ what RESCAP was
chartered to do. That last item, in my opinion, is not a requirement of 
digital rights management. Why do I have to use an identifier that is
registered with some third party? Most folks would like to be able to
manage the digital rights of http://www.joe-blow.com/music/my-music.midi
without having to create yet another identifier for it....

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

Sure. Everyone should consider the DNS to be at the end of its usefullness.
It was never intended to be any of the things you listed there.
Where did the DNS come into this anyway? I don't think anyone has made
the suggestion that currently deployed DNS infrastructure can handle 
any of this. This is why the URN working group did what it did. This
is why the IESG is creating uri.arpa as an infrastructure level Internet
technology for reliable, secure URI services such as caching/replication, 
metadata, access control, policy, etc...

There has been _considerable_ work done in the IETF in this particular area.
I'm just suggesting that this group use that work and not chuck all of it
in favor of one very verticle solution. Make the system modular and make
it use the identifier infrastructure that the IETF and the W3C are
standardizing on...

-MM

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