Registration and whitelisting flow, initial premises

• Done in completely automatic fashion. 
• SP needs to be listed in one of the metadata that SA is consuming, at the moment: eduGAIN, OpenAthens, SWAMID, InCommon
• Technical and Administrative contact from the SP metadata are taken as contacts that SA is recognising
• Advanced (and potentially Standard) implementors will need to register the API keys in order to call the persistence service API 
• For API key registration domain ownership needs to be proved by inserting a defined record in their DNS? 
• Once an API key is registered, there needs to be a process for renewal. It can be an automatic job, and the old key is left functioning if there is a job error. 
• During the registration process, SPs need to accept the terms of use: 
  • Advanced - registration flow in the website, part of click-through, policed through API key registration process 
  • Standard - registration flow in the website, part of click-through, policed through API key registration process if mandatory for standard
  • Limited - registration flow in the website, part of click-through, no way to police

Option 1 -Registration of the SP and acceptance of ToS

• Registration is done via seamlessaccess.org website. 
• Person that wants to register SP, chooses SP from the list which is being populated from metadata SA is consuming.
• UI presents the email addresses of the administrative/technical contacts that are registered with that SPs metadata.
• Person needs to choose one of the email addresses to prove s/he has access to it, and then clicks "send email"
• Person receives email with a link containing a long string. Click on that link takes s/he to the SP specific registration page on seamlessacccess.org
• This page shows some of the data about the SP that is parsed from the metadata, with message to correct this data through SPs published metadata if needed. 
• There are checkboxes to :
  • accept ToU (mandatory)
  • choose which SP contact email to add to the users mail list (optional)
  • choose which SP contact email to add to status notifications (?) (optional)
  • choose if it is advanced or standard integration
• For advanced integration, there is an approval process as well as the implementation needs to be approved by the SA.
•  After registration there is a log created - to be defined what information and in which format, and adding to the lists ? 

Option 1 - Registration of the API key

• Need to check if SP exists in the log created in the registration flow in the website 
• ... TO BE DESCRIBED BY LEIF
• SP admin uses curl call that is described in documentation. Shibboleth SP key is used to sign a message that is then sent to the API server.
• API server responds with JSON and key ?
• SP should place the key in the environment variable or in the file - documentation for this to be provided. 

Option 2 -Registration of the SP and acceptance of ToS via entity category 

• SP expresses its acceptance of ToS by adding entity category (which is TBD) to its metadata. Different EC are used for advanced and standard integration.
  • If SP's federation allows, SP adds EC themselves to the metadata
  • If SP's federation has strict policy and doesn't allow SP to tag metadata with SA EC, then SP needs to send email from administrative contact expressed in the metadata to SA contact to request to tag its metadata with SA EC. Then SA will in its metadata aggregate tag the SP's metadata with the EC. 
• Seamless Access scans at the metadata periodically (hourly?) and records a list of SPs that has the entity category tag. Each SP seen to use this entity category, is recorded together with timestamp, noting all the changes (add/remove EC). This data is needed to be able to keep the history. This will be done by pushing the MD aggregate to github. 
• Every change is being notified by email to ? 
• For the advanced integration, the SP needs also to contact the SA team to approve its implementation.  
• SA team maintains a list of SP's entityIDs that have been approved for advanced implementation.
• Based on SA metadata, we can have an internal and external view on who are SPs that use SA. 
  
  • internal view would be for the use by the SA team and would have basic info about SP,  contacts from metadata and which integration they use
  • external for start number of SPs using advanced and standard. 

Option 2 - Registration of the API key

• ... TO BE DESCRIBED BY LEIF
• SP admin uses curl call that is described in documentation. Shibboleth SP key is used to sign a message that is then sent to the API server.
• API server checks if the SP has entity category set in SA metadata and for advanced also if it is in the list of the approved ones. 
• API server responds with JSON and key ?
• SP should place the key in the environment variable or in the file - documentation for this to be provided.