Today SPs that want to use SeamlessAccess need to fill out a form in Airtable to request that their domains be whitelisted to be able to access the service. This is ONLY required for implementers that are ding the “Advanced flavor” of implementations. Those using the “Basic” and “Standard flavors” will not need to whitelist the call to API in these instances is made directly by SeamlessAccess.org.
The process
Those implementing the “Advanced flavor” of SeamlessAccess.org, will be directed to provide a request to whitelist the domains that they will be using when making API calls. Their request is shepherded through the process manually:
# | Step | Performed by |
1 | SPs send requests for white listing by filling in the form https://airtable.com/shrW1gq06nMazByEt. This request generates an email to laura@seamlessaccess.org. | Requesting SP |
2 | Requests are forwarded to the Operations team at ??? | SP Outreach |
3 | Once a week (on Fridays), the requested domains will be (manually) whitelisted. | Operations |
4 | White listed domains will be added (manually) to the Seamless Access Configuration Parameters list. SP Outreach is informed, by ??? | Operations |
5 | The whitelisted domains list in Airtable is updated to indicate that the request has been fulfilled, and requestors are informed via email. | SP Outreach |
Request form has a predetermined list of organizations! What about those not on the list?
Q: Submitter can pick only an institution from the list. What happens if the institution is not on the list?
A: In the intro text, individuals that don't find their names on the list are asked to contact me. In reality (and especially for the beta period), I don't think we want any organizations that we haven't been talking to gaining production access until they have spoken to us. All of the organizations that I have had any contact with (or have been mentioned in email threads) are already included in the database and will be available for selection
Who can submit a form?
Q: Is there any authentication mechanism behind sending a request. At least to check the ownership of the submitter email. If not, then anybody can send request impersonating the submitter.
A: You're right. This is not designed for high-throughput, unchecked requests. As currently implemented, it is assuming that I am in direct communication with the individual making the request because we're working with them directly on a Beta implementation. That said, it is possible to put in authentication and/or other controls. I just haven't.
Who gets requests? How are they processed?
Q: Can you please explain the notification flow which is happening in the background, which parts of it are automatic and which need a manual intervention i.e:
...
Leif indicated that he would like to process the requests once per week on Fridays. I think that process probably needs to be put into place. Once the request has been processed, someone needs to update Airtable - It can be me or Leif/Operations, whatever makes sense. If Operations makes the change to check the boxes, it can be used as a trigger notification to me to notify the requesting party. Or, you guys can just send me a note to let me know and I'll check the boxes and follow up.
How urgent is it to get something else in place?
Bottom line, though, is we should do whatever makes sense for this early phase of the project. Clearly what is currently in place will not scale as-is. I'm guessing it will take a while to get to the point where we are processing large numbers of requests each week. I expect it will stay in the 0-2 requests per week for quite a while (particularly since it is only those implementing the Advanced Flavor), so we likely have time before we put in place something very durable. This process also will need to include other onboarding activities like signing the terms of service, reaching out to SPs for document their user stories and get them listed on our site, etc.