Resource Identifiers: discussion synthesis

[Ray Plante]

Thanks, Tony,

> >  1. Q:  Should IDs carry any semantic information?
> >  A:  They can, but they are not required to.  More precisely, the ID 
> >      standard and its use in standard registry interfaces should not rely 
> >      on it.  
> 
> I assume you mean other than the fact that there are two components to the
> ID: AuthorityID and ResourceKey? So, agreed.

Yep.

> >   2. Q: Who controls the components of an ID?
> >   Revised A:  the registering data provider.  Thus, the AuthorityID no 
> >     longer implies the existance of any registry service specific to the 
> >     AuthorityID.  The specification merely requires that AuthorityID's
> >     are uniquely associated with organizations (or individuals) that
> >     own them. 
> 
> Less sure. I'm happy with the idea that an organisation can 'own' an
> authorityID but how is this determined? If it is based on certificates then
> it comes down to one individual. And all registries have to implement this
> ownership checking - and in the same way.

Yes, we definitely need a common way of doing this checking.  The
reservation that Tom expressed was one of tying the ID standard to
registries.  While I think he considers this fundementally a
philosophical issue, it could have some practical implications in the
near future.  One is that the way we do this ownership checking may
change in the future.  Tom suggested that early on, a fully secure
framework may not be necessary as we get things going.  This gives us
time to figure out the right way to do it right (e.g. applying the
model of individually owned certificates to assert group ownership).
The key thing is not to lock the ID spec to a particular method for
asserting and verifying ownership.

> How about a modification of the original idea: the registry can control
> *multiple* authorityIDs. These authorityIDs are 'owned' by organisations or
> users but one registry controls their allocation....
> 
> What do you think?

This all sounds consistant with discussions we've been having on this side 
of the pond.  In particular, there will need to be a mechanism, as you
say, where an organization reserves its authorityIDs.  

> The organisation then
> uses that one registry to register all its resources.

This is a registry implementation choice that may change with time.  Once we
have security infrastructure in place, it may be possible to allow an
organization to go to any registry to register resources with its
AuthorityID.   

> The most common way this would be used is for a data centre with a simple
> local registry serving one organisation to register one authorityID. But it
> also allows for one registry to serve multiple organisations. And it allows
> the organisation to choose its own authorityID. It also reserves the
> possibility that someone can set up a registry on our original basis for
> those who aren't bothered about the authorityID.

Yep, all good.  One caveat: we should allow organizations to "own"
more than one AuthorityID.  The scenario that was suggested at our
telecon today was that an organization may want to group all its
scientific resources under one AuthorityID (e.g. heasarc.nasa.gov) and
all its education and outreach under another
(e.g. heasarc-epo.ncsa.gov); it's completely their choice.  

> The only registry implementation that has to worry about checking that the
> 'owner' of an authorityID is registering under that id is the one
> controlling multiple authorityIDs but we don't have to mandate the same
> method of checking throughout the VO which we would have to do if we allowed
> people to register any resource with any authorityID at any registry.

I'd like to see our initial implementations being done in ways that
minimize the security issues; an example might be restricting users to
registering with a single registry.  Later implementations could ease
this restriction (which may require additional standardization).  The
main thing is not to make the general registry framework upon which we
base our implementations unnecessarily restrictive.  

So, good!  I think I can write up a working draft now!

cheers,
Ray