Policies

The following applies within WAYF and must be observed by participating organisations (service providers and user organisations):

In the event of any ambiguity, the Danish text shall prevail.

• Purpose. WAYF is the identity federation for research and education in Denmark and the North Atlantic, and its purpose is to securely and simply extend the scope of user accounts at Danish research and educational institutions to also include online services operated outside those institutions. Through collaboration with corresponding federations abroad, WAYF also facilitates the use of Danish and North Atlantic user accounts with online services in foreign federations and the use of foreign user accounts with web services connected to WAYF (see Inter-federation below).
• Admission and responsibility. Institutions may be admitted as user organisations if they belong to WAYF’s target group, which is public sector organisations and other organisations that meet the conditions for being able to subscribe to DeiC’s research network. A service provider may register its service in WAYF and thereby receive logins from WAYF’s user organisations if at least one of them wishes the service to be registered in WAYF. Service providers use WAYF at their own risk and without any liability for compensation on the part of WAYF, and they warrant that they will not make any use of user information collected via WAYF other than what they have agreed with the commissioning user organisations. WAYF may suspend service connections and exclude service providers in cases of serious breaches of the terms or other behaviour which WAYF considers likely to harm the federation. Service providers may at any time deregister services and withdraw from the federation, however without refund of any amounts paid. See also here for admission of user organisations and here for admission of service providers.
• Changes to the terms. WAYF may change these terms and does so regularly. WAYF aims to give notice of material changes prior to their entry into force. Participating organisations are, however, obliged to keep themselves up to date with what applies.
• Architecture. WAYF operates a hub between web services and authentication systems. Organisations participating in WAYF connect their systems to WAYF’s hub, and the systems communicate with each other via the hub. For providers who prefer it, WAYF offers an alternative technical connection model that emulates the architecture in which each connected system communicates directly with other connected systems (the so-called mesh architecture). Exceptionally, systems may be registered in WAYF’s metadata registry without being connected to the hub.
• Sessions. WAYF does not maintain any sessions for users who log in through WAYF. How long a browser has a session “with WAYF” is determined solely by how long the browser is logged in with the selected user organisation.
• Contact details. Service providers and user organisations are obliged to keep their contact details with WAYF up to date on an ongoing basis. If they do not, they risk, for example, not receiving notices and other important information from WAYF.
• Protocol profile. In WAYF, the rules in Kantara’s Federation Interoperability Implementation Profile apply as a general rule. As a rule, you cannot rely on WAYF supporting anything other than what, according to that profile, must be supported. WAYF may specify deviations from the profile, in particular restrictions. Most notably, WAYF supports only browser-based protocol traffic, and no server-to-server communication. — With its hub, WAYF has the technical potential to translate between different federation protocols and also provides experimental support for WS Federation Passive Requester and OIDC (only the id_token flow) for services.
• Traffic signing and responsibility. User organisations must sign the Assertion element and may sign the Response element in login responses to WAYF. Service providers may, but do not have to, sign login requests to WAYF. WAYF itself accepts and issues signatures only with SHA256 as the hashing algorithm used. WAYF validates signatures only on login responses, and no signatures on other protocol messages. Every connected organisation must validate every signature in protocol traffic from WAYF. WAYF cannot be held liable for damage caused by a connected organisation’s failure to validate signatures, timestamps or audience restrictions.
• Signing keys. Signed protocol messages to WAYF must be signed with a private key corresponding to a public key of at least 2048 bits. The key must be provided to WAYF contained within a base64-encoded X.509 certificate. Pursuant to WAYF’s protocol profile, WAYF regards the “certificate” solely as a technical format for the key and thus not as a proper PKI certificate; WAYF does not take account of any content in the X.509 structure other than the key itself. WAYF signs self-issued protocol documents (both traffic and metadata) with private keys in hardware corresponding to 2048-bit public keys.
• Federation attributes. WAYF supports the exchange of user information according to the schema here. User organisations must provide values for every MUST attribute in every login response to WAYF. WAYF does not forward syntactically malformed attribute values in the login response from the user organisation to the service provider. Based on other received values, WAYF constructs values for the attributes eduPerson(Scoped)Affiliation and displayName if the user organisation does not itself supply them in the login response to WAYF. Similarly, WAYF constructs values for the attributes schacYearOfBirth and schacDateOfBirth, if the user organisation does not itself supply them, based on the value of schacPersonalUniqueID if that is provided. CPR numbers are provided only to service providers that are either public sector organisations or act on behalf of public sector organisations.
• Encryption. All login traffic to and from WAYF must take place via HTTPS. Connected organisations may not provide WAYF with protocol endpoints that do not begin with https://. The Assertion elements of login responses may, but need not, be encrypted at the XML level. WAYF can XML-encrypt login responses to service providers that require this. XML encryption is an additional encryption of parts of the protocol document on top of the encryption at the TLS level.
• Processing of personal data:
  • Description. Each time a user attempts to access a connected web service via WAYF, WAYF receives a set of information about them from their institution and passes on to the service provider the subset thereof that the provider needs to process in order to deliver its service to the user or the user’s institution. Immediately after disclosure, all data except the user ID are deleted; the user ID is pseudonymised before being stored in WAYF’s log. 
  • Data responsibility. WAYF is a data processor for each connected user organisation. It remains the responsibility of the data controllers to ensure a valid legal basis for the processing of personal data that takes place when WAYF is used, and to ensure that data subjects are sufficiently informed about the processing that takes place in connection with the use of WAYF. It may be that WAYF’s processing can generally be regarded as having a legal basis in the performance of a contract between the user and their institution (user organisation). It is of no concern to WAYF whether the service provider that receives the institution’s information in login tickets is a data processor for the institution or collects the information as a new data controller.
  • Data minimisation. When connecting, WAYF advises each service provider on data minimisation and thereafter discloses only the user information to the provider whose processing has been found necessary. It remains, however, the service provider’s responsibility not to carry out unnecessary processing of personal data conveyed by WAYF.
  • End-user notice. WAYF informs the user (the data subject) about the disclosure of personal data the first time they log in to a given service from a given institution. This can, however, be disabled and should be disabled if the service provider is identical to, or a data processor for, the user organisation. WAYF’s end-user notice serves to increase the transparency of personal data processing for the user and is not necessarily a fully sufficient notice of the start of processing in the sense of data protection law.
• Time tolerance. WAYF does not process protocol messages that are more than 3 minutes old. WAYF can determine the age of a message correctly only if the clock on the sending organisation’s server is reasonably accurate. WAYF’s time policy must be complied with.
• Logout. WAYF supports full single logout to the extent that the connected systems do so. If the user has a session with more than one identity provider, WAYF even logs them out of them all.
• Endpoint quality. Connected organisations must not provide WAYF with endpoints that do not work. Endpoints found not to work must without undue delay either be made to work or be removed from metadata.
• Data quality. Each user organisation in WAYF is obliged to maintain its user information such that no information received by WAYF is more than 24 hours out of date. In addition, incorrect user information must not be conveyed to WAYF. WAYF will take action if violations are discovered.
• Opt-out. Any web service connected to WAYF, as a general rule, has access to receive logins from any institution connected to WAYF. If an institution so wishes, it can block specific services from receiving logins from it.
• Request requirement. WAYF does not process login responses that do not correspond to a received login request. In other words, WAYF does not support (what in the SAML2 protocol is called) unsolicited responses.
• NameIDFormat. For service providers, WAYF supports transient, persistent and emailAdress; for user organisations, only transient. WAYF does not support other NameIDFormats, e.g. not unspecified.
• Subject. When WAYF receives a login request with a Subject element, WAYF forwards it to the user organisation; but WAYF merely mediates the transactions and assumes no responsibility for whether a corresponding login response from the user organisation actually relates to the user identified in the request’s Subject element – this is (as essentially everything else) a matter between the service provider and the user organisation.
• Inter-federation. If at least one of WAYF’s user organisations wishes to be able to access a web service in another eduGAIN federation, WAYF makes the service available to all its user organisations and minimises the amount of user data it receives. Any web service in eduGAIN that has been marked by its federation as Research&Scholarship, however, is available to WAYF’s user organisations without further ado. Any service provider in WAYF may receive logins from foreign user organisations in eduGAIN if they so wish.
• Metadata quality. Participating organisations must ensure that connected systems always use valid metadata from WAYF — and must keep connected systems’ metadata with WAYF up to date. Only with the express permission of WAYF may WAYF metadata be used for purposes other than connecting systems to WAYF. Use of WAYF metadata is at your own risk.
• EntityID quality. The EntityID in SAML connections that a member organisation registers with WAYF must be a URN or a URL; the namespace or domain must be under the organisation’s demonstrable control, or the EntityID as a whole must be demonstrably assigned to the member organisation by the organisation that owns its namespace or domain. The latter implies, for example, that Azure AD tenants may be registered in WAYF.
• RequestInitiator. Every service provider is encouraged to implement and then register a RequestInitiator endpoint in WAYF’s metadata for their service.
• Entity categories. Providers that need their metadata entities to appear with specific entity categories in eduGAIN must contact the WAYF Secretariat to have the labelling carried out. The REFEDS entity categories Research&Scholarship, Code of Conduct and SIRTFI are not in systematic use within WAYF, but are supported for metadata entities that are to be exported to eduGAIN. Only Hide from Discovery is interpreted within WAYF – where the discovery service does not show login systems with that metadata tag.
• Discovery. Each time WAYF receives a login request from a particular service, WAYF forwards the user to the login location that they have permanently selected for that service. If they have not selected a permanent login location, WAYF lets them choose their login location from a list. The user can revoke a permanent selection of login location on the site my.wayf.dk.
• Prohibition on embedding. It is not permitted for native apps to access WAYF through WebViews or embedded browsers that may allow the app to intercept the user’s passwords or similar.