Clients may use pull management which is illustrated in Figure 4.

Figure 4 – Device Authentication using Pull Management

See 7 for a complete description of the Device authentication process.

The sequence begins when the Device discovers the location of the Registrar via mDNS (see OPC 10000-12), the SetRegistrarEndpoints Method is called (Servers only) or the Endpoints are provided via a Device specific mechanism. The sequence automatically repeats until the Device receives its DCA Certificate and no software update is required. Any errors occur the sequence restarts from the beginning. Note that step requires that the DCA trust any Registrar it finds since it does not have a valid TrustList (see 4.2.4).

If multiple Registrars are on the network, the DCA shall attempt to connect to each one until it finds one that accepts it and allows it to request a DCA Certificate and a TrustList. Once configured, the DCA shall not attempt to connect to Registrars that are not in the TrustList. Devices that support pull management shall have a way for a person with physical access to the Device to reset the DCA TrustList and restart the Device authentication process.

The OwnerOperator should have a strategy to detect and remove rogue Registrars since the DCA always trusts the first Registrar that provides an Application Instance Certificate.

Once connected to a Registrar the Device provides all of its DeviceIdentity Certificates to the Registrar which then attempts to locate a valid Ticket that matches one of the Certificates. If a Composite Ticket that matches the Device ProductInstanceUri exists then only DeviceIdentity Certificates with the CompositeInstanceUri are considered by the Registrar.

If no Ticket is found the Registrar asks the Device to provide any Tickets that it has by returning a Bad_TicketRequired error.

If a valid Ticket is found the Registrar returns a DeviceIdentity Certificate and ApplicationId which the Device is expected to used to request the DCA Certificate and the DCA TrustList.

The Registrar also uses the Ticket to determine if a software update is required before it provides a Certificate to a Device. If one is required it returns a Endpoint to the SoftwareUpdateManager that the Device is expected to use.

When the Device connects to SoftwareUpdateManager it provides the current version number of the software that is installed. If it is the required version, the SoftwareUpdateManager calls the UpdateSoftwareStatus Method. Otherwise, the Device downloads the update, applies it and then connects to SoftwareUpdateManager again and provides the new version number. The process repeats until the required software version is installed.

The complete process for requesting a Certificate and a TrustList are described in OPC 10000-12. Note that the DCA does not call RegisterApplication on the CertificateManager since the Registrar does that on behalf of the DCA when it finds a valid Ticket for the Device. Note that the Methods exposed by the Registrar rather than the CertificateManager. The expectation is the Registrar and the CertificateManager share a common backend so Certificates and Applications created via the Registrar will be known to the CertificateManager. In some cases, the Registrar and the CertificateManager will be the same Server.

The GetManagers call returns the Endpoints for the CertificateManager which the DCA is expected to use.

The DCA shall not connect to an untrusted Registrar once it has a TrustList.

The process for requesting Application Instance Certificates is shown in Figure 5.

Figure 5 – Requesting Certificates using Pull Management

The DCA registers all Applications it intends to manage with the Registrar which verifies that the DCA is authorized to manage the Applications and provides ApplicationIds needed to request Certificates from the CertificateManager. This authorization process is specific to the Registrar implementation and can include communication with an external authorization service or manual approval by a RegistrarAdmin.