N.B. On first reading it may be advisable to skip this section as understanding of flows shown in Fig-19 will be useful.
One of the fundamental principles of the Core Security Architecture is use of federations, which may support persistent or transient identifiers. When correctly used, these types of identifiers allow privacy to be preserved by not leaking any correlation handles. This section addresses Reqs. D1.2-2.14-Priv, D1.2-7.8-NoColl, and D1.2-7.16-Nym.
In order to implement persistent and pseudonymous federations, the IdP and IM have to keep state. In general, the federation table for an IdP that supports persistent pseudonymous identifiers will hold mappings as follows:
User at IdP1 --> [ encrypted pseudonym of user at SPA,
encrypted pseudonym of user at SPB,
...
encrypted pseudonym of user at SPN ]
The federation table for IM needs similar mappings
User's pseudonym at IM --> [ encrypted pseudonym of user at SPA,
encrypted pseudonym of user at SPB,
...
encrypted pseudonym of user at SPN ]
The IdP and IM may include attribute data in the tokens they emit. This attribute data can be kept in any suitable data structure, usually indexed by user and sometimes by SP, or both.
The IM needs additional data structure to determine what services are available to a User. In its simplest form this would consist of
User's pseudonym Service Type SP EntityID ---------------- ------------ ------------- 789IM Role Author. C.example.com 789IM HR Authority B.example.com 579IM Role Author. C.example.com 579IM HR Authority B.example.com
but other more general realizations can include data needed for Trust and Privacy Negotiation phase of Discovery. These will be explored in the Trust and Privacy Negotiation documentation.
An IdP may have a limited form of this table to cover the necessity of emitting IM bootstrap token during SSO.
All parties - IdP, IM, and SP (FE or WS) - need to maintain some metadata about each other. Such metadata may include SOAP endpoints, protocol profiles and bindings to use, etc. These will generally be specified in protocol specific documents as adopted in Annex A "Protocols", but for general idea the reader may want to see [SAML2meta].
There is also the requirement for a user to be able to aggregate his attributes together in order to gain access to web services. This requires an attribute linking service, which is fully described in [TAS3D71IdMAnAz].