[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Handle-globus] Handle-URI data-model ramblings
HandleUriDataModel
To look at it from a more formal perspective, one could distinguish a
tuple of:
(NA-context, NA-admin-context, community-context, subject-name,
subject-attribute-name, subject-attribute-type, subject-attribute-value)
where:
NA-context: the NA-assigned prefix, the NA's identity, the unit of
administrative deployment
NA-admin-context: the name space under the prefix that is managed and
owned by the top level NA-admins, it's up to them to delegate the
authority of handle management to others.
community-context: a (sub-)name space that is managed by the community's
admins, who in turn have been empowered by the top-level NA-admins to do
so. Furthermore, the top-level NA-admins will enforce a policy that new
names in that community's name space will be managed by that community only.
subject-name: the actual name to which the attribute values will be
bound. The same subject-name can be bound to many different attributes
by many different communities.
attribute-name: the identifier for the attribute that is bound to the
subject.
attribute-type: the type associated with the attribute value
attribute-value: the actual data value of the attribute as it is bound
to the subject by the community.
---
The proposal is to associate URIs (or IRIs) with the community-context,
subject-name, attribute-name, and attribute-type.
We could make the following observations:
* the community-context is an identifiable entity that can be
communicated between parties to distinguish different subject-attribute
bindings for the same subject. Through a naming convention, knowing the
community-context's URI would allow one to construct a handle of where
the community context's sub-name-space is maintained by a NA. Knowing
that complete community-context-handle, the administrative HS for that
community would be implicitly identified.
* when the community-context URI equates a authenticatable identity,
like a public key, secret, kerberos principal, then one should use the
convention that that community-context is the associated identity: the
sub-name-space is owned by that identity.
* having no community-context would implicitly make the ownership of
the associated subject-handle and the binding of subject-attributes the
responsibility of the HS-admins: the community-context is essentially
the NA-admin-context.
* if the subject's attribute-name's URI uniquely identifies a record
element or element/attribute in an xml-document, then it also implicitly
identifies the associated data-type, which would make the latter
somewhat redundant as it could be found through a semantics
investigation of the attribute-name.
* as the subject's attribute-name is a URI, we could construct a handle
that would manage binding information associated with that object, like
data-type, schema definition, etc.
* The combination of "community-context"+"subject"+"attribute-name"
refers to a subject's attribute as it is maintained within that
community-context. Different communities or handle owners can bind
different subject's attribute-values to the same subject's attribute-names.
* The combination of the "NA-context"+"NA-admin-context" would give the
handle-prefix under which the different communities can manage their own
subnamespace of the handles.
---
For example, we could have a handle:
12.34/communities/uri:http://communities.org/compute-vo;uri:ldap:///cn=john%20doe
where:
"12.34/communities/" identifies the "NA-context"+"NA-admin-context"
where the top-level handle-admins are the only ones responsible for
managing the handles.
"uri:http://communities.org/compute-vo"; identifies the
"community-context" that is responsible for the name bindings in the
subnamespace underneath.
"uri:ldap:///cn=john%20doe"; identifies the subject to which the bindings
apply as they are administered by the community.
---
Another example with a single subject managing handle values as they
apply to an other subject would be:
12.34/communities/uri:ldap///cn=mary%lou;uri:ldap:///cn=john%20doe
In other words, one will find the attribute bindings for john as they
are administered by mary.
Note that although mary is the initial admin for the subnamespace
underneath "her" DN, she can empower others to do the admin also and
even be removed from the initial admin list.
This example also shows that there are some names for communities that
seem to be "owned" by those communities in a "natural" way through the
ownership of the trademarks/ip-names or associated security credentials,
like private keys.
For communities identified by certain DNs or keys, it would be
straightforward only to accept the creation request by those that can
prove the associated credential ownership, like secrets or private keys.
Ownership of other names may not be easy at all...
By letting the NA-admins manage the community name assignment, they
could provide unique names that guaranteed won't have conflicts with
anything else - maybe something based on GUID/UUIDs.
For example, I could ask for a new, unique community-context to work
with, and the NA-admins will issue me the ownership of a handle
subnamespace based on a UUID, like:
12.34/communities/uri:uuid:757bc90-e9f3-11d9-8cd6-0800200c9a66
As I will be the owner, I could use it to bind attributes to subjects
that I care about within my newly created context. I could also add new
administrators and build my new community without the issues of name
clashes and such.
---
Hierarchical NA administration.
Ideally, you would like to hand out the complete control of a
subnamespace to a community without any needed intervention from
top-level admins.
This would be possible through assignments of NA-prefixes, like:
{{{
12.34.uri:http:\/\/communities.org\/compute-vo/
(not sure how to escape the "/" correctly...)
}}}
This would have the added advantage that this same subnamespace becomes
an administrative unit that can be replicated and (re-)homed.
To accommodate the potential explosion of NA-prefixes, this would
require a hierarchical admin feature that will allow NA-admins to manage
their own extended prefix assignment and management independent from the
root.
---
--
Frank Siebenlist franks@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory
_______________________________________________
Handle-globus mailing list
Handle-globus@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-globus