To Whom It May Concern:
Thank you for offering the opportunity for public feedback through Department of Education Request for Information (#2014-08649), entitled "Request for Information on the Use of APIs in Higher Education Data and Student Aid Processes."
The technology trends of both the country as well as the world have clearly shown that API adoption and integration are crucial to any and all modern organizations. I've included responses to your questions below and strongly encourage you to engage on this topic with a significant increase in focus and attention. Avoiding this arena further imperils the Department's mission and the interests of the constituents it serves.
Thank you kindly,
Gray Brooks
Section A. Information Gaps and Needs in Accessing Current Data and Aid Programs
Section A, Question 1: How could data sets that are already publicly available be made more accessible using APIs? Are there specific data sets that are already available that would be most likely to inform consumer choice about college affordability and performance?
Response:
Large datasets that are currently available as flat files may be bulky or unwieldy. APIs can provide the means for easier consumption and integration of the data, as well as faster prototyping.
To the latter question, almost certainly. The Department would be best served by reviewing website analytics, site search queries, download statistics, FOIA requests, and public feedback mechanisms to prioritize these efforts.
Section A, Question 2: How could APIs help people with successfully and accurately completing forms associated with any of the following processes: FAFSA; Master Promissory Note; Loan Consolidation; entrance and exit counseling; Income-Driven Repayment (IDR) programs, such as Pay As You Earn; and the Public Student Loan Forgiveness program?
Response:
In each case, different consumers may find different user interfaces better suited for them. Thus, a plethora of quality options are most likely to ensure that more users are better served. APIs also allow innovators to apply new and improved techniques to these processes well in advance of when the Department may have a chance to do so.
Section A, Question 4: What services that are currently provided by title IV student loan servicers could be enhanced through APIs (e.g., deferment, forbearance, forgiveness, cancellation, discharge, payments)?
Response:
Each discrete aspect of each service could be enhanced through APIs. Private sector innovation has clearly shown that the designing any of these services today would employ reliable and well-documented service calls at each level.
Section A, Question 5: What current forms or programs that already reach prospective students or borrowers in distress could be expanded to include broader affordability or financial literacy information?
Response:
Each of them. There is no reason to suspect that any form or program is already doing a perfect job. Integration and iteration of modern web services (APIs) can clearly play a part in improving user experiences and efficiencies each time.
Section B. Potential Needs To Be Filled by APIs
Section B, Question 1: If APIs were available, what types of individuals, organizations, and companies would build tools to help increase access to programs to make college more affordable?
Response:
Interested partner organizations that desire improved an education system or advocate for students and consumers; independent app developers that are interested in solving problems that they experienced; small businesses; non-profits; schools; local and state governments; and the Department.
Section B, Question 2: What applications and features might developers, schools, organizations, and companies take interest in building using APIs in higher education data and services?
Response:
The possibilities are endless. At its simplest, third-party applications based on the APIs may seek to create alternative or superior user interfaces to what is currently offered. Developers may also take the form of combining datasets and/or services in new and innovative ways. On one level, these may simply be useful mashups but on another, it can result in entirely new ways of structuring traditional processes in ways that prove superior to the status quo.
Section B, Question 5: Would APIs for higher education data, processes, programs or services be useful in enhancing wraparound support service models? What other types of services could be integrated with higher education APIs?
Response:
To the first question, yes. To the latter, honestly, the sky is the limit - APIs unlock innovation to an unparalleled degree.
Section C. Existing Federal and Non-Federal Tools Utilizing APIs
Section C, Question 1: What private-sector or non-Federal entities currently offer assistance with higher education data and student aid programs and processes by using APIs? How could these be enhanced by the Department's enabling of additional APIs?
Response:
To the latter question, yes.
Section C, Question 2: What private-sector or non-Federal entities currently work with government programs and services to help people fill out government forms? Has that outreach served the public and advanced public interests?
Response:
To the first question, education institutions, non-profits, community organizations, and businesses of all stripes have filled this role. Certainly this outreach has served the public and should be empowered by the Department. The degree to which the Department unlocks data and services via API will proportionately empower these efforts.
Section C, Question 3: What instances or examples are there of companies charging fees to assist consumers in completing otherwise freely available government forms from other agencies? What are the advantages and risks to consider when deciding to allow third parties to charge fees to provide assistance with otherwise freely available forms and processes? How can any risks be mitigated?
Response:
To the second question, at issue is the pro-consumer innovation that is made possible when businesses are able to compete to provide better functionality and user experience to a process. Risk-avoidance in this sense runs the risk of shuttering valuable markets that would serve the public well. That said, market efficiencies can be combined with an intentional developer terms of service applied to Department APIs to shape the norms that third parties must respect to consume the Department's APIs.
Section C, Question 4: Beyond the IRS e-filing example, what other similar examples exist where Federal, State, or local government entities have used APIs to share government data or facilitate participation in government services or processes—particularly at a scale as large as that of the Federal Student Aid programs?
Response:
At the federal level, a listing of hundreds of APIs can be found at the below locations:
-https://raw.githubusercontent.com/18F/API-All-the-X/gh-pages/_data/individual_apis.yml
-http://18f.github.io/API-All-the-X/pages/developer_hubs
Scores of these APIs can compete with the size of this program. As examples, NOAA, Census Bureau, USGS, EPA, and NASA each offer large number of very large data APIs. HHS and the Department of Energy has numerous individual APIs that provide access to gigabytes of data.
Section D. Technical Specifications
Section D, Question 1: What elements would a read-write API need to include for successful use at the Department?
Response:
To this end, please review the following:
http://18f.github.io/API-All-the-X/pages/best_practices
http://18f.github.io/API-All-the-X/pages/agency_checklist
http://18f.github.io/API-All-the-X/pages/developer_hub_kit
http://18f.github.io/API-All-the-X/pages/api_release_kit
http://18f.github.io/API-All-the-X/pages/agency_maturity_model
Section D, Question 2: What data, methods, and other features must an API contain in order to develop apps accessing Department data or enhancing Department processes, programs, or services?
Response:
The primary requirement is that the API provide reliable and well-documented access to each layer of data or functionality that is at issue.
Section D, Question 3: How would read-only and/or read-write APIs interact with or modify the performance of the Department's existing systems (e.g., FAFSA on the Web)? Could these APIs negatively or positively affect the current operating capability of such systems? Would these APIs allow for the flexibility to evolve seamlessly with the Department's technological developments?
Response:
To the last question, yes.
Section D, Question 4: What vulnerabilities might read-write APIs introduce for the security of the underlying databases the Department currently uses?
Response:
Read-Write APIs do not inherently introduce novel vulnerabilities. Instead, they bring into more clear relief the dynamics that are necessary for all modern systems management by removing those dynamics from obscurity. More on the issue can be found here -
http://18f.github.io/API-All-the-X/pages/api_security
Section D, Question 5: What are the potential adverse effects on successful operation of the Department's underlying databases that read-write APIs might cause? How could APIs be developed to avoid these adverse effects?
Response:
Any potentially adverse effects - such as greater loads - would be tied to more direct and intentional utilization of the systems. One common source of hesitation results from the increased ease with which flawed data may be uncovered but resistance to APIs as a result is a form of avoiding the problem instead of benefiting from the process to improve it.
Any and all adverse effects could be readily avoided by planning, designing, and implementing APIs in conjunction with the community of API producers across the federal government that have already faced and worked through such risks and have solutions readily at hand. GSA now offers several forms of API support and engagement that are available for the Department to employ on demand: http://18f.github.io/API-All-the-X/pages/support
Section D, Question 6: How should APIs address application-to-API security?
Response:
To your question:
http://18f.github.io/API-All-the-X/pages/api_security
Section D, Question 7: How should the APIs address API-to-backend security issues? Examples include but are not limited to authentication, authorization, policy enforcement, traffic management, logging and auditing, TLS (Transport Layer Security), DDoS (distributed denial-of-service) prevention, rate limiting, quotas, payload protection, Virtual Private Networks, firewalls, and analytics.
Response:
Developers have publicly documented thoroughly and robust methods of addressing each of these issues. Please feel free to contact GSA for direct support to plan an implementation that accounts for them - http://18f.github.io/API-All-the-X/pages/support.
Please also note that GSA now offers federal agencies a shared service that addresses nearly all of these out of the box - http://api.data.gov/about. It is available for use today and is already being satisfactorily used by 8 other agencies.
Section D, Question 8: How do private or non-governmental organizations optimize the presentation layer for completion and accuracy of forms?
Response:
User testing, robust analytics, and dogfooding their own workflows.
Section D, Question 10: With advantages already built into the Department's own products and services (e.g., IRS data retrieval using FAFSA on the Web), how would new, third-party API-driven products present advantages over existing Department resources?
Response:
The potential innovation of the rest of the Internet has consistently shown it's role in complementing existing resources. To put it mildly, no federal agency is in a position to claim a unique role that can not be improved by third parties. Regardless of how good an existing offering may be, competition will only make it better while simultaneously allowing for the possibility that someone else may build a better mouse trap.
Section D, Question 11: What would an app, service or tool built with read-write API access to student aid forms look like?
Response:
It could look similar to existing offerings or reflect alternative theories of what an optimal workflow might look like. It could integrate the registration process into other relevant processes. Most importantly, though, is unlocking the potential for ideas beyond what the Department currently contemplates.
Section E. Privacy Issues
Section E, Question 1: How could the Department use APIs that involve the use of student records while ensuring compliance with potentially applicable statutory and regulatory requirements, such as the Family Educational Rights and Privacy Act (2*: U.S.C. 1232g; 3*: CFR Part 99*: and the Privacy Act (5 U.S.C. 552*: and 3*: CFR Part 5b)?
Response:
These would be issues of API design that, while non-trivial, would certainly not be novel. GSA offers API consulting to federal agencies that could assist the Department in this process.
Section E, Question 2: How could APIs ensure that the appropriate individual has provided proper consent to permit the release of privacy-protected data to a third party? How can student data be properly safeguarded to prevent its release and use by third parties without the written consent often required?
Response:
This is an issue of data management that would be present regardless of the presence or absence of APIs. The architecture and workflow of such processes is simply enhanced by allowing automation in between the human decision points.
Section E, Question 3: How might read-only or read-write APIs collect, document, and track individuals' consent to have their information shared with specific third parties?
Response:
APIs allow for quick and completely digitized access to any layer of information, including what individuals have chosen at any number of points in the process.
Section E, Question 4: How can personally identifiable information (PII) and other financial information (of students and parents) be safeguarded through the use of APIs?
Response:
APIs can be constructed to provide clearly defined and managed access to discrete rows, columns, or tables of each dataset. This is superior to human workflows that may make a mistake in manually curating access.
Section E, Question 5: What specific terms of service should be enabled using API keys, which would limit use of APIs to approved users, to ensure that information is not transmitted to or accessed by unauthorized parties?
Response:
Model developer terms of service can be found here - https://github.com/GSA/API-Resources/tree/master/developer_tos#readme. Note that it may not be recommended to carve out specific clauses to call out the issues in this question. Several dozen agencies have already offered APIs with developer terms of service and have collaborated to suggest the models linked above.
Section E, Question 6: What are the relative privacy-related advantages and disadvantages of using read-only versus read-write APIs for student aid data?
Response:
The advantages of write APIs stem from having greater functional control over the use of this data, including by internal users, as well as more granular and useful analytics to allow more mature and intentional data management. There are no inherent privacy-related disadvantages to write APIs.
Section F. Compliance Issues
Section F, Question 1: What are the relative compliance-related advantages and disadvantages of using read-only versus read-write APIs for student aid data?
Response:
The advantages of write APIs stem from having greater functional control over the use of this data, including by internal users, as well as more granular and useful analytics to allow more mature and intentional data management. There are no inherent compliance-related disadvantages to write APIs.
Section F, Question 2: How can the Department prevent unauthorized use and the development of unauthorized products from occurring through the potential development of APIs? How might the Department enforce terms of service for API key holders, and prevent abuse and fraud by non-API key holders, if APIs were to be developed and made available?
Response:
To the last part of your question, there are plenty of robust options for ensuring that API use is only allowed by authorized parties, for instance, through well-managed OAuth2-based keys.
By stating clear and reasonable requirements in the official developer terms of service, the Department can position itself to respond quickly and firmly to any instances of violations of those terms, either that the Department observes or that is reported to them through public reporting. The Department would be able to offer a public reporting functionality (both on their website and - via embed or write API - on partner websites) that would allow consumers to easily report potential violations.
An API-based model actually better positions the Department to respond to inappropriate reuse of Department workflows than the traditional model, since the latter lacks a digital system with robust usage analytics.
Section F, Question 3: What kind of burden on the Department is associated with enforcing terms and conditions related to APIs?
Response:
The Department would be able to easily shape this burden to be of any size and shape that it finds appropriate to support its mission and resources.
Section F, Question 4: How can the Department best ensure that API key holders follow all statutory and regulatory provisions of accessing federal student aid funds and data through use of third-party products?
Response:
By offering access through a well-constructed registration system that requires contact info and tracks follow up usage (esp. the location of the 3rd party integration).
By reviewing the 3rd party sources of data calls.
By offering strong, user-friendly methods for reporting non-compliance by consumers and by compliant third-party developers.
Section F, Question 5: How could prior consent from the student whom the data is about be provided for release of privacy-protected data to third party entities?
Response:
Perhaps by integration into existing prior-consent workflows. Otherwise, an update to the language currently used by the student's initial data submission may be useful.
Section F, Question 6: How should a legal relationship between the Department and an API developer or any other interested party be structured?
Response:
A developer terms of service that is integrated into API key generation.
Section F, Question 7: How would a legal relationship between the Department and an API developer or any other interested party affect the Department's current agreements with third-party vendors that operate and maintain the Department's existing systems?
Response:
In many cases, a review of existing agreements may find sufficient flexibility to the language that nothing need change. Certainly, the Department would want to reconsider and update any agreements that inhibit the best end result for its consumers.
Section F, Question 8: What disclosures should be made available to students about what services are freely available in government domains versus those that could be offered at a cost by a third party?
Response:
It may be that existing disclosures already adequately address this.
Section F, Question 9: If the Department were to use a third-party application to engage with the public on its behalf, how could the Department ensure that the Department follows the protocols of OMB Memorandum 10-23?
Response:
There is significant precedence available from GSA and the Web Managers community within the federal government to address there. Agencies have readily used numerous third-party ideation platforms, feedback engines, and issue trackers to great effect and without any difficulty conforming to OMB 10-23. The application of these tools in the scenarios outlined in this RFI should face no unique difficulty.
Section G. Policy Issues
Section G, Question 1: What benefits to consumers or the Department would be realized by opening what is currently a free and single-point service (e.g., the FAFSA) to other entities, including those who may charge fees for freely-available services and processes? What are the potential unintended consequences?
Response:
The primary benefits are two-fold: greater opportunities for the consumers to have an improved user experience and greater efficiency for the Department.
By enabling third parties to better compete to provide improved functionality and user experience to consumers, the Department would remove itself from being the single point of failure for the consumer user experience. Small businesses and large, innovators and traditional parties - a huge range of potential parties have an interest in competing with the Department to make a better user experience for the service. Some may charge fees that users would gladly pay in order for a superior user experience but just as many woulds find other means of justifying development in this area. The only 'loser' from the this perspective would be the Department's interest in being the sole provider of a service - a motive at variance with the best interest of the consumers. Ask the same question around NOAA's weather data. If NOAA was weighing the choice of whether to allow API access to it's weather data or whether to be a no-cost, sole provider. Clearly their move to allow a third party ecosystem to flourish around their data has resulted in more options for consumers that provide superior user experience than the agency by itself would ever have been able to provide, both at a paid and unpaid level.
The other major benefit is to the Department's own efficiencies. The API stories of Netflix, Google, Amazon, Apple, NPR, NYTimes, Salesforce, and so many more directly tell the story of API production that is *first and foremost* an issue of internal efficiency. Data transfer and team interoperability is greatly improved when staff can manage and maintain systems through modern, mature web services.
The potential unintended consequences are all cathartic - possibly overdue needs in the realm of data management that have been allowed to plague systems because of the resilience of the status quo.
Section G, Question 2: How could the Department ensure that access to title IV, HEA student aid programs truly remains free, even amidst the potential development of third-party apps that may charge a fee for assistance in participating in free government programs, products, and services with or without providing legitimate value-added services?
Response:
The best step would be to ensure a ensure a free, quality option that successfully competes with 3rd party offerings not by exclusive access but rather by being the best option for consumers.
However, the Department could conceivably include any number of requirements in its developer terms of service to promote good behavior by 3rd party developers and enforce compliance through a robust use and curation of api key access. One could even go so far as to require that certain services only be used by no-cost products, though such a move would risk stifling important and positive innovation.
Section G, Question 3: What other policy concerns should the Department consider with regard to the potential development of APIs for higher education data and student aid processes at the Department?
Response:
The concerns raised in this RFI, combined with the existing policies and procedures of the Department should be sufficient.
Section G, Question 4: How would APIs best interact with other systems already in use in student aid processes (e.g., within States)?
Response:
The best method is to ensure that the Department offer and use themselves the same set of quality, well-documented read/write APIs. By dogfooding both internally and with partner systems (e.g. within States) the same APIs, the Department would be best positioned to have all parties interact with these APIs in the most productive and positive fashions.
Section G, Question 5: How would Department APIs benefit or burden institutions participating in title IV, HEA programs?
Response:
Department APIs would benefit institutions by opening up an entire market of potential products and services that would provide a superior user experience for these institutions than the Department currently - or ever will - be able to provide itself. If the Department continues to allow the institutions to use their default offering directly from Education, then there would not be a need for any burdens to arise.
Section G, Question 6: While the Department continues to enhance and refine its own processes and products (e.g., through improvements to FAFSA or the IDR application process), how would third-party efforts using APIs complement or present challenges to these processes?
Response:
This is question of version management and backwards compatibility that has been well worked through by the private sector.