RE: [uddi-spec] UDDI Spec TC Agenda 20050524 Telecon

["Tong Jin" <tong_jin@bah.com>]

Luc,

I will not be able to participate in today's telecon. But here are my
comments on the "key partition" TN.

Overall, my comments are around the preciseness of key partion
definitions and rules.

I. A typo in line 171, "suffix" should really be "prefix",
right?

II. Key partition definition

Key partitions are defined in line 169 on page 6 as
"a UDDI mechanism to ..."

then later, in line 175, page 6, it says
"A UDDI node administrator is the owner of the root
partition..."

This seems to imply that a UDDI node administrator owns a
"mechanism".

Here is my suggestion (possibly superfluous)

"2.1 Definitions
...
Key partitions (line 169)

A key partition is a SPACE for creating UDDI keys using a
unique key prefix string. By ensuring that the key prefix is
unique to a publisher, global uniqueness is ensured so long as
the publisher assigns a unique prefix to the UDDI key of each
published object.

A key partition has a name, which is the string to be used as
the prefix for all UDDI keys in this partition. For example, the
root partition has a name of "uddi:".

A key partition is represented by a key generator tModel, this
applies to all UDDI key partitions except the root
partition. By owning a key generator tModel, an organization is
said to own the key partition it represents."

III. Rules for UDDI key partition

It is not very clear the distinctions among "key partition",
"UDDI key prefix", "key generator (tModel)" in this section.

My comments and suggested changes are inline with the original
text:

1.	A UDDI node administrator is the owner of the root
partition - "uddi:"

2.	Any sequence of letters, numbers, escaped characters (which are
represented by % hexdigit hexdigit) or characters from the set ; / ? @ &
= + $ , - _ . ! ~ * ' ( ) may be appended to a key partition (separated
by a colon) to create a UDDI key.  These appended characters are called
the key specific string (kss). The string "keygenerator" is not an
allowed kss.

3.	A key partition owner may create a child key partition by
appending the special string ":keygenerator" to a key.  For example a
registry node administrator may create a new partition for ACME by
publishing a key "uddi:acme-com:keygenerator".
[Jin:]
Comment -- Unclear how can some one publish a "key" without a
UDDI object? I interpret it "as a key generator tModel is
Published".

Comment -- Unclear whether the "key" to be appended with
":keygenerator" is a UDDI key for a publish UDDI object or is it
just a valid "key string" in the partition space. I interpret
it as the actual child partition name. There may be no UDDI
object with this "key"

Suggested changes:
A key partition owner may create a child key. The child key
partition name is formed by appending a valid "kss" to its
parent partition name. Such a child key partition is
represented by a key generator tModel. The key generator tModel
MUST have a special UDDI key formed by appending
":keygenerator" to the child partition name. The owner of the
key generator tModel is said to own the child key partition
space, and hence is allowed to create new UDDI keys in this
child partition space. For example a registry node administrator
may create a new partition for ACME by publishing a key
generator tModel with UDDI key "uddi:acme-com:keygenerator",
hence creating a new partition "uddi:acme-com".

4.	Key partitions SHOULD be based on the DNS domain of the owning
organization.

5.	The owner of a key generator key can transfer ownership to
another registry user.  In this case the new owner of the key generator
key becomes the owner of the key partition it represents.  For example,
if the registry administrator creates "uddi:acme-com:keygenerator" to
the ACME administrator then ACME is the new owner of the "uddi:acme-com"
key partition and can create new keys in the partition by appending a
key specific string (kss) as defined in rule 2.
[Jin]
Comment -- unclear how can a user own a UDDI key in UDDI. Again,
a UDDI key is just a property of a UDDI object (of one of the 4
key data types).

Suggested changes:

The owner of a key partition can transfer the ownership of
the key partition to another registry user. This is accomplished 
by transferring the key generator tModel for the key partition to
the new owner. For example, if the registry administrator creates
"uddi:acme-com:keygenerator" key generator tModel to the ACME
administrator then ACME is the new owner of the "uddi:acme-com"
key partition and can create new keys in the partition by
appending a key specific string (kss) as defined in rule 2.

6.	Once a key generator ownership is transferred the original owner
may no longer create keys in the partition represented by the key
generator.
[Jin]
Suggested changes: add "tModel" after "key generator" in both
places.

IV. Owning Organization and Owner/User/Publisher
As I understand it, identity management in UDDI registry is
beyond the scope of UDDI spec. However, sorting out the
relationships among users (and possibly "roles") in the spec/TN
may be important.

One striking thing I noticed is the mentioning of "owning
organization" and users ("publisher"/"administrator") for the
organization. It is said a key partition is owned by an
organization and should be based on the DNS domain of the
organization. Where are the organizations defined/stored in the
UDDI registry? Where does the linking of users to "owning"
organizations happen?

I hope this can be discussed first before proposing a possible
solution on security policy in section 2.2.2.

V. Security Policy
Section 2.2.2's proposal of using PKI certificate has other
limitations besides the one mentioned.

Most deployments of UDDI registry (private/enterprise-wide) use
username/password authentication, not digital cert (neither
ws-security digital cert authentication, nor 2-way SSL in a
web app).

Even in the situation where each UDDI user is issued a digital
cert and the UDDI registry can use the digital cert to
authenticate the user, within an enterprise boundary, it is very
unlikely each cert contains the fine-grained department/branch DNS
domain info. So how can the registry prevents an HR user from
creating a key partition for uddi:acme-com:finance child
Partition?

I feel this is a bigger topic and may be scoped out of this TN.

Thanks,

Jin Tong
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phone 703-917-2839      ||  Booz | Allen | Hamilton
Fax   703-902-3457      ||  8251 Greensboro Drive
Email Tong_Jin@bah.com ||  McLean VA 22102
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~