3.4 Subject of the PII Not Present -Transaction

There are two main categories for supporting PII-Subject-Not-Present transactions

1. PII Subject consented at some earlier time.

   If the consent was expressed by the PII Subject by creating a policy that authorizes the delegation, then we need to establish from the audit trail that only the user could have created the policy.

   If token based delegation is used, PII-Subject-Not-Present could be implemented by "cacheing" an access credential for long time. Due to obvious problems with long term valid access credential, we only allow cacheing the discovery bootstrap credential. Using this credential the WSC MUST request a fresh access credential for the PII-Subject-Not-Present transaction immediately before attempting the transaction. This ensures that the PII Subject has control and visibility since the Discovery will be a third party to the transaction, allowing additional audit correlation. Discovery can also be used as centralized revocation point for the consent to the off-line transaction up to the point when the transaction is actually made.

   The discovery token was originally issued for a purpose and when a transaction token is requested, including the PII-Subject-Not-Present situation, a purpose MUST be declared so that the authorization process at the discovery can make appropriate decisions.

2. Transaction is permitted by law or contract without consent of the PII Subject. In this case the big problem is that as the PII Subject might never have been present we need to consider how the Legitimate Initiator (LI) identifies the PII Subject in the first place.

   1. The PII Subject has a federated account at the Legitimate Initiator. In this case the LI can ask the IdP to issue a discovery token. Such issuance needs to be strictly controlled. The LI is first authenticated (e.g. using PKI at TLS level) and then LI presents the legitimate purpose why the token is sought. The IdP will consult a PDP which will make the policy decision whether under these circumstances the discovery token should be issued. The audit trail shall rigorously reflect these events. After the discovery token has been obtained, the rest of the steps are as in (1).

   2. The PII Subject has an account at the Legitimate Initiator, but it is not federated. The issuance step of (a) will have additional request to create the federation. If the PII Subject eventually ends up using the LI through SSO, the already created federation will be used.

   3. The PII Subject does not have an account anywhere. In this case a stand-in account needs to be created first and then the process of (b) and (a) will be followed. If the PII Subject eventually starts using the LI using SSO, a problem remains on how to associate the PII Subject to the already existing account. This may be possible by asking some identifying information, such as sector specific or national identifier upon first SSO use. If asking such information is infeasible, or the PII Subject can supply wrong information, we may well end up with user having two accounts at the LI. Depending on the circumstances, this may not be a problem, or an administrative procedure may be needed to combine the accounts.