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

Wed, 23 May 2001 14:34:13 -0400

>Date: Wed, 23 May 2001 13:50:34 -0400
>From: Michael Mealling <michael@neonym.net>
>Subject: Re: [IDRM] DRM Taxonomy work -- drm framework... -- handle system
>To: "Sam X. Sun (@S2000)" <ssun@cnri.reston.va.us>
>Cc: Michael Mealling <michael@neonym.net>, ietf-idrm@lists.elistx.com
>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 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