*Goal*
Goal is to configure SATOSA to act as a lightweigth proxy service that can bridge between SAML2 (SAML2INT) IdP and various Authentication Sources (AuthSources) using multiple protocols. The infrastructure provide a single endpoint for 'Guest' Authentication Sources. It should be as invisible as possible, and have only minimal enduser interaction. Finally it should not store any personal data

Examples of proxy scenarios the service should support include:
* SAML2 (SAML2INT) <-> SAML2 (SAML2INT) IdPs, e.g. UnitedIDP, Feide OPenIDP, ONEGini, EduID.se and other 'Guest' IdPs that live in national R&E federations
* SAML2 (SAML2INT) <-> SAML2 (other profiles) IdPs
* SAML2 (SAML2INT) <-> OIDC OPs, including (but not limited to) Google
* SAML2 (SAML2INT) <-> OAuth-isch Social Providers (initially: Facebook, Twitter, Linkedin)

*Proxy*
The proxy has 2 sides: 
* the 'SP' side, which is facing the various AuthSources (also know as RP for OIDC)
* the IdP side with must presenting itself as a SAML2INT, eduGAIN complient SAML2 IdP

*IdP attributes*
The IdP may deliver a small attribute set, using the eduPerson Schema, consisting of:
* email address (mail), 
* name (all of CN, SN, GivenName, DisplayName)
* identifier (SAML nameID, eduPersonTargetedID
The ability to deliver these attributes is subject to both what the AuthSource is providing, and to user consent.

The IdP side must deliver a per user, persistent identifier (PiD), in the form of a SAML persistent NameID, as well as a eduPersonTargetedID 

*Persistent Identifier (PiD)*
The persistent identifier is created on a per user basis, as a SHA512 hash created independently of the AuthSource that was used. The PiD is stored in the UserAccount, which will never sore any data unencrypted or in a non pseaudonymous form.
The relation between the PiD and the SHA512 hash of the persistent user identifier provided by the AUthSource should be stored in a mapping table. For performance reasons the mappings could be cached in e.g. Memcache. 
In time, multiple relations between PiD and AuthSources could exist.
The PiD may not change per SP requesting an authentication.

*Consent*
An authentication request at the proxy must result in a redirect to an appropriate AuthSource, as selected by the user (see [IdP Discovery]). Upon succesfull authentication, the AuthSource must resturn a persitent user identifier, and could return attributes. Authsources that cannot return a persistent identifier cannot be used. Email shall not be used as a persistent identifier.
Before continuing to release the authentication and attributes to the requesting SP, consent must be asked from the user. 
The user may choose to not release name or email, on a per SP basis. The user may choose to re-evaluate this release policy in 1 month, 1 year or never. 
The identifier will always be released if the user chooses to continue the transaction. The only way for the user to not release the identifeir is to cancel the transaction. In that case, the proxu service will signal "not authenticated" to the SP.

A SHA512 hash over SP endentifier (entityID), selected attribute names and values, should be stored to prevent asking for consent again should the information to be released remain the same. Any change in either attribute set, or attribute values must result in a new consent request. The interface of the consent screen should follow recommenationas as laided out in [REFEDs]

*IdP Metadata and Discovery*
IdPs metadata must be published automatically per AuthSource connected to the proxy. This will allow SPs to select individual IdPs behind the proxy who they want to work with. The proxy will handle AuthN requests transpatently, so each AuthSource will have its own Authentication endpoint on the IdP side of the proxy.
Metadata must comply with eduGAIN Metadata requirements, any information that is needed for this, but cannot be determined programatically should be read from a (per Idp?) config file.

*SP Metadata and Client registration*
In case relevant for the AuthSource, SP SAML metadata will be published. Client registration is done manually for OAuth clients

*Multi Language Support*
Any GUI that is represented to the enduser should be multi language capable, and should detect language preference from local browser. Text and button label elements should be configurable, however initially only an English and Swedish version will be provided.

*Account recovery* 
The service will not support account linking or account recovery, this is left up to the SP. The servcie will provide information on the AuthSources used to handle the authentication, an will to the best of its abilities notifiy SPs if a connected IdP is about to go away.

*Statistics*
The service will keep a log of transactions by counting the frequency an IdP was used to access a given SP. This information will become publicly available at a "stats" endpoint proviced by te service for the benefit of the SPs. No personal data will be collected at any time.

*Level of Assurance / SAML Authentication Context*
Every authentication will contain an authentication class statement describing the LOA of the authentication based on eIDAS. If a SP requests a specific LOA scheme, anfd this LOA is know to the service, the requested scheme will be used.

*Mapping LOA*
The per IdP LOA mapping will be configured in a config file for each LOA scheme. By default, the servcie will provide a LOA based on the eIDAS LOA schema. VOs and/or Federations may provide a LOA scheme via an out of band mechanism which should follow the predefined configuration