Each of the calls in the publisher's API that change information at a given UDDI-enabled server requires the use of an opaque authentication token. These tokens are generated by or provided by each UDDI-enabled server independently, and are passed from the caller to the UDDI-enabled server in the element named authInfo .

These tokens are meaningful only to the UDDI-enabled server that provided them and are to be used according to the published policies of a given UDDI-enabled server.

Each party that has been granted publication access to a given UDDI-enabled server will be provided a token by the site. The methods for obtaining this token are specific to each UDDI-enabled server.

Before any party can publish data within a UDDI-enabled server, credentials and permission to publish must be supplied with the individual operator. Generally, you will only need to interact with one UDDI-enabled server because all data published at any UDDI-enabled server are replicated automatically to all other such servers. Establishing publishing credentials involves providing some verifiable identification information, contact information, and establishing security credentials with the individual server. The specifics of these establishing credentials is server-dependent, and all valid UDDI-enabled servers provide a Web-based user interface through which you can establish an identity and secure permission to publish data.

Every registry implementation that adheres to these specifications establishes its own mechanism for token generation and authentication. The only requirement placed on token generation for use with the publisher's API is that the tokens themselves must be valid string text that can be placed within the authInfo XML element. Given that binary-to-string translations are well-understood and in common use, this requirement will not introduce hardships.

Authentication tokens are not required to be valid except at the UDDI-enabled server or implementation from which they originated. These tokens need only have meaning at a single UDDI-enabled server or implementation, and should not be expected to work across sites.

Many implementations are expected to require a login step. The get_authToken message is provided to accommodate implementations that desire a login step. Security schemes based on exchanging User ID and password credentials fall into this category. For implementations that desire this kind of security, the get_authToken API is provided as a means of generating a temporary authentication token.

Certificate-based authentication and similar security mechanisms do not require this additional step of logging in. Instead, they can pass compatible authentication token information such as a certificate value within the authInfo element provided on each of the publisher's API messages. If certificate-based authentication or similar security is employed the use of the get_authToken and discard_authToken messages is optional.