Delegated Access Validation

The validation process runs when the proxy clicks the I Accept or I Decline button on the Proxy Terms and Conditions page, enters the security key and email address, and, optionally, some personal information, then clicks the Submit button. The validation process contains the criteria to make sure the right person is trying to access the delegator’s data. This is needed because at the time of delegating access, the delegator and the system have no technical knowledge about the proxy. Both do not know the proxy’s user ID or whether an EMPLID exists for the proxy. All they know is the proxy’s name, email address, and relationship with the delegator.

Using the security key and the email address entered by the proxy on the Proxy Terms and Conditions page, the validation process associates the proxy (proxy’s user ID) with the delegator (delegator’s EMPLID). This is possible because the security key is unique for the delegator-proxy combination. Once the validation is successful, and if the proxy has accepted the terms and conditions, the system updates the proxy’s user profile by provisioning the security roles associated with the delegated transactions. If the proxy declined the terms and conditions, provisioning is not performed and the delegated transactions are automatically revoked.

If at least one of the delegated transactions is set up with the Assign EMPLID to Proxy option selected, the system uses the first corresponding CTM transaction code encountered to trigger Search/Match, and an an EMPLID is assigned to the proxy.

The proxy validation process is performed only once per proxy-delegator combination. If a proxy is already registered and has been validated and tied to a specific delegator, the proxy does not go through this validation again. This validation logic is performed as part of the SCC_DA web service. The SCC_DA web service contains the SCC_DA_SUBMIT (Delegate Access Submit) service operation.