In the August 8 issue of .NET UPDATE, we started looking at the new features in Universal Description, Discovery, and Integration (UDDI) 3.0. In this column, I discuss UDDI's new support for digital signatures. Digital signature use has a twofold purpose. First, by signing data in a UDDI registry, publishers of the data can be sure that they can't be impersonated. Second, users of digitally signed data in a registry can be sure that the identified publisher of the data is genuine and that the data hasn't changed since it was published. Support for digital signatures lets anyone who queries a UDDI registry view only entities that have been digitally signed.
UDDI 3.0 supports digital signing of any of five elements: businessEntity, businessService, bindingTemplate, tModel, and publisherAssertion. (Of these, businessEntity is the top-level element and the other elements are children, related in descending order.) Data is signed when it's published to the UDDI registry, but the mechanism for signing needs to be in place before then. The UDDI specification recommends that digital signatures use well-known key formats to make identifying and validating a signature easier for client applications.
Because the goal of digital-signature capability is to enable anyone searching a UDDI registry to distinguish between signed and unsigned data, publishers of data in a UDDI registry should calculate digital signatures for the top-level element in the UDDI registry according to rules laid out in the Worldwide Web Consortium's (W3C's) Recommendation document "XML-Signature Syntax and Processing" (available at http://www.w3.org/TR/xmldsig-core ). That is, the publisher should place the data's signature according to how the data is published. For example, if data is published as a service, the signature should be calculated on the businessService element, which becomes the top-level element; if the data is published as a business, the signature should be calculated on the businessEntity element. The signature applies to all child elements for published data unless the use of a transform file specifically excludes applying the signature to a child element. Therefore, when businessService elements are signed, the bindingTemplate element in the published UDDI data will also be signed (unless excluded), and when the businessEntity element is signed, the businessService element will be signed.
The new support in UDDI 3.0 for entity promotion (a device that lets a publisher propose a new identifying key for an entity rather than rely on an automatically generated key) is important for making digital-signature functionality work. Entity promotion makes copying elements to new registries without breaking the signature file possible by letting the publisher name the entity key rather than rely on the node to automatically generate the key, which would invalidate the signature. For a signature to be valid, it needs to be generated before the data it's associated with is published in the UDDI registry. Therefore, the UDDI specification recommends that anyone who publishes data in the registry should generate a digital signature only on elements with publisher-assigned keys. Signatures on elements with node-assigned keys (i.e., automatically generated keys) will work only if the node will not generate additional keys.
An application searching a UDDI registry examines the top-level element (such as businessService, in the earlier example) that the registry returns to verify whether the element has a signature. To validate the signature, the client machine that runs the application searching the registry must examine the keys in the signature.
To examine the complete UDDI 3.0 specification, go tohttp://uddi.org/pubs/uddi_v3.htm
End of Article
Register
