[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec-comment] Question on UDDI v3 keys
I have a question on UDDI v3 keys ... in a deployment UDDI environment, what would the process be to ensure that domain owners authorize the use of their domain names as v3 key components?
<lc>How key partitions are created and managed is ultimately a matter of governance for the enterprise. I expect an organization will manage and assign its key-spaces much in the same way it manages internal DNS domains today. Depending on the implementation used, I expect the enterprise will select a root key-space when it installs its first v3 registry; this key-space would then be used as the default key-space for node-generated keys. As a means of implementing and enforcing this, I would suggest that the node administrator is the only “role” granted the ability to generate a key-space (i.e. is permitted to generate keyGenerator tModels).
It is likely that subordinate or other key-spaces may also be required to deal with the case of federated nodes or simply needed a different key-space for use within a node. In either case, the administrator of the node would create the subordinate or other key-spaces requested and perform an ownership transfer (via the ownership and custody transfer API or some UI) of the key-spaces’s keyGenerator tModel to the intended owner of the key-space.
is a controlled means of generating key spaces and a round-about way to answer
your question. In short, the administrator has control to whom it grants the
creation of key-spaces and thus has a means of enforcing enterprise
The way that I see it, it would be possible for me (not an owner of
xyz.com) to beat XYZ, Inc. to a public registry and create a key generator that looks like uddi:xyz.com:services:keygenerator unless the operator validates that the owner of the key root (the domain name) authorizes the use of the key. Do you know if operators are prepared for this in some way? Or will this be rationale to continue using v2-styled keys until there is some form of DNS-related integration of some sort -- and would this even help?
<lc>As described above, control over the generation of key-spaces by a node administrator does provide you with a means of ensuring that you don’t have a free-for-all.
One might want to create a self-serve environment whereby anyone is granted the ability to generate key-spaces. In such an environment, it is quite likely that someone might attempt to create a key-space and squat on it (much in the same way that domain squatters do this today). This is entirely not acceptable as you suggest, and as such node policy would require that the publisher provide proof of ownership/association of the domain for which he/she is attempting to create a key-space for (through the creation of a domain keyGenerator tModel).
Policy enforcement might be implemented in a number of ways; the tModel keyGenerator might actually not be persisted and ready for use until such time validation has been performed for example. Validation might take different forms: it might be manual or it might be automated. One way to automate this is to require the domain keyGenerator tModel to be digitally signed and requiring that certain properties of the signer’s certificate be available to associate the user with the domain requested. There are clearly other ways of implementing this.
short, I do not anticipate an implementation would allow uncontrolled generation
of domain-based keys, as allowing uncontrolled generation is unwarranted and
simply that – uncontrolled.</lc>
I have not seen this dealt with/mentioned by the UDDI committee ...
<lc>The spec stays clear of making normative a behaviour; it is not its place. What the TC is in the process of writing is a technical note that describes practical examples of using domain-based keys. A work in progress can be found at .
Am I missing something?