Modernizing Financial Aid Delivery

1
Modernizing Financial Aid Delivery

• Jim Farmer
• instructional media magic, inc.
• As presented at the
• School and Lender Spring Workshop
• Education Assistance Corporation
• Tuesday, February 27, 2001 and Wednesday,
  February 28, 2001
• Aberdeen, South Dakota and Bloomington, Minnesota

2
Modernization is

• A term used by federal and state government
  referring to information technology initiatives
  designed
• from a citizen (student) users perspective
• to provide improved service
• at lower cost.

3
The unknowns

• Students response to e-commerce and e-government
• Schools capacity and preferences for
  modernization
• Implementation capacity of
• Office of Student Financial Assistance
• Guaranty agencies
• Lenders
• Servicers
• Software developers

4
Implementation is limited by

• IT talent, especially those knowing both the
  application and the new technology
• IT budgets
• Ability of the industry to work together,
  especially on standards
• Capacity of the organizations to accept change

5
Students, schools have a choice

• Paper forms and mail
• Web-based transactions
• School-based systems
• Specialized systems
• Enterprise systems
• Integrated systems
• Outsource financial aid services
• or any combination

6
Challenges to financial aid delivery

• Improving service
• Lowering unit cost
• Retaining and replacing financial aid
  professionals
• ______________________
• Increasing available funds for postsecondary
  education

7
Todays agenda

• Background of Modernization
• SFA Performance
• Current and planned SFA Initiatives
• The Meteor Project, an example of the technology
• Electronic ID
• Observations and Recommendations

8
Project EASI to the PBO
9
Project EASI 1997 - 2000
Project EASI Provided a Concept, Requirements,
and Transition Strategy for Modernization

• Recommendations from the Project
• Provide the Customer a Single Point of Interface
• Create a Student-, Prospective Student-, and
  Family-focused System
• Reduce Costs, and Improve Program Integrity and
  Oversight
• Support Life-long Learning at Multiple Schools

Concept Document, June 23, 1997
10
Student Financial Assistance

• The Governments First
• Performance-Based Organization
• A Performance-Based Organization (PBO) Shifts
  the Focus of Government From Red Tape to
  Results.
• The PBO Concept WasApplied in a Solid,
  Bipartisan Way by the Department (of Education)
  and a Congress...It Is a New Way to Run the
  Government.
• COO Greg Woods, Swearing In Ceremony, Dec 8, 1998

11
SFA Performance Objectives, 2000

• Increase Customer Satisfaction Index to the Range
  of Americas Best Financial Service Companies.
• Reduce Unit Cost by Twenty Percent
• Increase Employee Satisfaction Rating to the
  Level of Workers Who Reach for the Stars

Interim Performance Objectives 1999
12
Modernization Strategies

• Integrate the Information Systems ... a
  Transition Strategy for Planning and Managing the
  Simultaneous Replacement of All of the Existing
  Title IV Systems With an Enterprise Data Base and
  Six Application Modules.
• Implementing the Higher Education Amendments of
  1998
• Advisory Committee on Student Financial
  Assistance
• January 1999
• Buy a Little, Test a Little, Fix a Little
• Modernization Blueprint, April 30, 1999

13
Why Buy a Little, Test a Little
Harry Feely, Project EASI Has Graduated, Aug 28,
1999

5
14
Why Buy a Little, Test a Little

• High performance, reliable Middleware is now
  available Lowers Risk of Failure
• Immediate cost savings
• Virtual Data Center now cost-effective
• Customer Interaction Center improves
  satisfaction, reduces unit costs

15
Key Technology Drivers

• Building on the Internet
• Shortening the Development Life-Cycle
• Emphasizing Skills
• Streaming Technology
• Voice, data and video
• Investing in Information Management Technology
• Customer Resource Management
• Data Warehouse
• Data Mart
• Steve Hawald, Software Developers Conference, Mar
  10, 2001

16
Web-Enabled Applications

• FAFSA on the Web
• Schools Portal Release 2.0 with Single Sign-On
• Financial Partners Portals FY 2002
• Student On-line Access to Direct Loan Servicing
• API to SFA Systems
• Specifications 09/30/01

17
SFA Initiatives for 2001

• 1. Turbo FAFSA
• 2. Common Origination and Disbursement
• 3. Financial Management System with E-Business
  Center
• 4. NSLDS Mad Dog Changes
• 5. Schools Portal with Single Logon
• 6. E-Signature and Promissory-Note
• 7. Consistent Answers for Customers
• (Contact Centers, CRM, Customer Data)
• 8. Human Resources Support System
• 9. Product Support Analysis

18
SFA Initiatives for 2001

• 1. Turbo FAFSA
• 2. Common Origination and Disbursement
• 3. Financial Management System with E-Business
  Center
• 4. NSLDS Mad Dog Changes
• 5. Schools Portal with Single Logon
• 6. E-Signature and Promissory-Note
• 7. Consistent Answers for Customers (Contact
  Centers, CRM, Customer Data)
• 8. Human Resources Support System
• 9. Product Support Analysis

19
SFA Performance
20
Customer Satisfaction

• 1999 2000 Change
• Federal Government (Overall) 68.6 68.6 0
• Student Financial Assistance 63 70 7
• Internal Revenue Service 74 75 1
• (e-file only)
• Fed. Emergency Mgmt. Agency 73 73 0
• U.S. Mint 86 84 -2
• American Customer Satisfaction Index
• University of Michigan Business School

21
Reducing Unit Costs
SFA FY2001 Performance Plan
Each dollar reduction represents 14 million
annual savings
22
FAFSA Savings Reinvestment
23 million
Investment in Information Technology
Operating Costs
SFA
Electronic FAFSA
23
SFA CIO Score Card - 2000
B

• New Management Team
• Training
• IT Policy Guide

Management

• Rational Rose Tools
• IBM MQ series - EAI/ Middleware
• LDAP Compliance / BI Tools
• RSA COTS tools
• XML Compliance Applications
• Informatica - ETL tools
• Digital Signatures
• Published APIs

• N-Tier Web Application
• Coupled VDC Migration
• Designed Data Warehouse
• SLAs in Place
• Migrating to Seat Management
• OPS Readiness Review
• Designed Portal Apps
• Internet/VPN

Operations
Technologies
24
Software Development Life-Cycle
New Forces
New Players
Change
Killer Applications
Exploiters
Death of Brands
Victims
Time (6 Months)
Steve Hawald, Software Developers Conference, Mar
10, 2001
25
Modernization of Financial Aid Delivery
26
Financial aid delivery - Then and Now
THEN
NOW
Driving Customer Principal objective Financi
al aid delivery system design SFA customer
service
Student Service at the lowest unit
cost Information Technology Industry Leading
School Service at any cost Regulations Indust
ry Lagging
27
Students expect

• Web-based services
• with current, complete information
• available 24 hours a day, 7 days a week
• from any location
• with a single sign-on

Single sign-on will require either shared
authentication or pin aggregation (automatic
sign-on from stored user names and pins)
28
Most Satisfied Customers
Transaction Type
Score
Electronic
75
Paper
48
Internal Revenue Service, Percentage
satisfaction, by type of filer
Customers Using Electronic Services Are More
Satisfied Than Those That Dont.
Steve Hawald, Software Developers Conference, Mar
10, 2001
29
Web ApplicationFAFSA on the Web - 1999/2000
Web ApplicationFAFSA on the Web - 2001
30
FAFSA On The Web
31
Common Origination and Disbursement

• Common Record based on CommonLine XML and IFX
  Forums LoanML
• Accommodates Pell, Direct Loan, FFELP,
  alternative loans, and potentially state grants
• Both real-time, single transactions and batch
  multiple transaction data exchanges planned
• School pilot in 2001, Phase in 2002-2005
• Industry standards

32
Common Record

• From Richard Tombaughs presentation to the
  Common Origination and Disbursements Task Force
• February 22, 2001 Meeting
• and planned presentation at the
• March 10, 2001 Software Developers Conference

33
Common Record Components

• Project has three component parts
• Identification of data elements
• Determination of data edits
• Creation of business messages

Richard Tombaugh, Common Record Status Report,
February 22, 2001
34
Identification of Data Elements

• Approach taken
• Identify all data exchange activities in which
  schools currently engage
• Identify the data elements that are exchanged in
  each such activity
• Develop crosswalks of all programs having
  common or similar transactions
• Separate the crosswalks into logical XML blocks

Richard Tombaugh, Common Record Status Report,
February 22, 2001
35
Approach Taken (continued)

• Review similar work being done elsewhere in the
  industry (PESC/ANS, IFX Forum, LoanML,
  CommonLine)
• Engage in dialogue with these other initiatives
  to reduce redundancy and maximize consistency
• Attach XML tags to each common element, using
  IFX Forum naming conventions (including the use
  of work already done by IFX Forum and expanded by
  CommonLine committee)

Richard Tombaugh, Common Record Status Report,
February 22, 2001
36
Approach Taken (continued)

• Subject crosswalk drafts to scrutiny of program
  experts (SFA staff, industry committees, user
  groups, 3rd party software developers, etal.)
• Incorporate input from reviewers
• Review work to ensure that all data elements have
  been included and that tags are unique
• Present recommended data element dictionary to
  SFA and industry for adoption

Richard Tombaugh, Common Record Status Report,
February 22, 2001
37
(No Transcript)
38
(No Transcript)
39
Review similar work

• SFAs Conceptual Enterprise Data Model
• NCHELPs CommonLine (XML version)
• IFX Forums LoanML
• ED AACRAOs Postsecondary Student Data Handbook
  
• PESC XML Forum
• ANSI aid origination, loan guaranty, and
  enrollment verification standards
• Educause Eduperson initiative

40
COD, an analysis

• Changes the paradigm of financial aid delivery
• Improves service, reduces costs
• Offers colleges and universities an integrated,
  simplified service on an aggressive schedule, but
  later than Meteor
• ----------------------------
• Creates an incentive for the student loan
  industry
• NCHELP CEO Conference, Session on
• Software Development, Jan 11, 2001

41
Schools portal

• Introduces portal concept to additional colleges
  and universities
• Design consistent with good Web designs in other
  words, it is attractive and functional
• Personalization of portal display
• Single SFA signon for financial aid professionals
  (Fall 2001)
• Focuses consistent organization of federal
  materials and services
• Integrated with customer interaction center

42
Web Portals - Schools Portal 03/01
43
Why a portal?

• User and provider choices of content
• Authentication/aggregation
• Personalization and preferences
• Continuity of user experience
• Portals benefits user
• Convenience and efficiency
• Portals benefit provider
• Context for presentation
• Continuity of experience
• Knowledge of the customer user

44
SFA portals, an analysis

• Set a minimum standard of design and function for
  portals
• Increases market share because of design, first
  contact
• Provides single signon
• Increases self-service transactions (lowering
  costs)
• Decreases and changes the form of customer
  interaction center contacts

45
Customer Interaction Center

• Improves the Quality of All Services
• Consolidates Call Centers
• Customer Resource Management (CRM) Standards
• Provides On-line Access to All SFA Systems
• Supports Customer Self-service Via IVR, E-mail,
  Web-access

46
School alternatives

• Methods of exchanging data with SFA
• Use paper forms, manual procedures, and mail
• Use the SFA school portal for manual entry,
  automated processing
• Use school-based financial aid systems
• Batch exchanges of data
• Real-time transactions

47
The Meteor ProjectA preview of SFA
implementations
48
Meteor wrote

• The Meteor Project is developing
• prototype open source software
• to permit a partner to display or use
  student-specific federal financial aid data
• in real-time,
• using Office of Student Financial Assistance API
  specifications.

49
Diagram of Meteor Concept
Web Services HTML
Meteor XML
Student Access Provider Data Provider
50
Pilot implementation ...
Web Services HTML
Meteor XML

Student
National Student Clearinghouse
Guaranty Agency, Lender, or School
51
As implemented ...
Web Services Secure HTML
Meteor Secure XML
Standard Browser
uPortal
Meteor SOAP
Meteor SOAP
Database
52
The development configuration
Linux Apache Tomcat
Linux Apache Tomcat
uPortal
Standard Browser
uPortal
Meteor SOAP JAVA Components
Meteor SOAP JAVA Components
Database JDBC Connection
53
The demonstration

• To show the operation of Meteor, the
  demonstration presentation included the uPortal
  with a Meteor Channel on the top half of the
  screen and a secure telnet session showing the
  flow of traffic--specifically the SOAP messages
  that included in the XML content--to and from the
  Meteor server, on the bottom half. (A sample
  screen follows)
• The demonstration was a dial-in connection, to
  the Internet, accessing servers in the
  Washington, DC office. The dial-in connection was
  operating at 28.8 Kilobits per second (roughly
  2,900 characters per second) . The message
  turnaround was less than one second.

54
Split screen demonstration
55
Student Meteor Channel - Entry
56
Meteor XML Request message

• gtgt(Tue Jan 09 115058 EST 2001) Processing SOAP
  request...
• ltSOAP-ENVEnvelope
• xmlnsSOAP-ENV"http//schemas.xmlsoap.org/soa
  p/envelope/"
• xmlnsxsd"http//www.w3.org/1999/XMLSchema"
• xmlnsxsi"http//www.w3.org/1999/XMLSchema-in
  stance"gt
• ltSOAP-ENVBodygt ltns1getLoanHistory
• SOAP-ENVencodingStyle"http//xml.apa
  che.org/xml-soap/literalxml"
• xmlnsns1"urnifx-loan-server"gt
  ltIFXRequestElgt ltIFXgt
• ltSaisSvcRqgt
• ltRqUID/gt
• ltSPNamegtgov.studentclearin
  ghouselt/SPNamegt
• ltLoanHistoryRqgt
• ltCustIdgt
• 
  ltSPNamegtgov.ssalt/SPNamegt
• 
  ltCustPermIdgt448377707lt/CustPermIdgt
• lt/CustIdgt
• ltDateOfBirthgt1980-09-0
  3lt/DateOfBirthgt
• lt/LoanHistoryRqgt

57
Meteor XML Response message 1

• Launching query ...
• gtgt(Tue Jan 09 115059 EST 2001) Sending SOAP
  response...
• ltSOAP-ENVEnvelope
• xmlnsSOAP-ENV"http//schemas.xmlsoap.org/soa
  p/envelope/"
• xmlnsxsd"http//www.w3.org/1999/XMLSchema"
• xmlnsxsi"http//www.w3.org/1999/XMLSchema-in
  stance"gt
• ltSOAP-ENVBodygt ltns1getLoanHistoryRespons
  e
• SOAP-ENVencodingStyle"http//xml.apa
  che.org/xml-soap/literalxml"
• xmlnsns1"urnifx-loan-server"gt
  ltreturngt ltIFXgt
• ltSaisSvcRsgt
• ltStatusgt
• ltStatusCodegt0lt/StatusC
  odegt
• ltSeveritygtInfolt/Severi
  tygt
• ltStatusDescgtSuccessful
  l Retrievallt/StatusDescgt
• lt/Statusgt
• ltRqUID/gt
• ltSPNamegtgov.studentclearin
  ghouselt/SPNamegt

58
Meteor XML Response message 2

• ltCustInformationgt
• 
  ltDateOfBirthgt1980-09-03lt/DateOfBirthgt
• ltPreviousPermIdgt
  lt/PreviousPermIdgt
• ltFormerLastName/gt
• lt/CustInformationgt
• ltStudentStatusgt
• 
  ltCurrentlyEnrolledgtYlt/CurrentlyEnrolledgt
• lt/StudentStatusgt
• ltLoanInformationgt
• 
  ltLenderIdTypegtOPEIDlt/LenderIdTypegt
• 
  ltLenderIdgt824607lt/LenderIdgt
• 
  ltLenderNamegtOklahoma Student Loan
  Authoritylt/LenderNamegt
• 
  ltSchoolIdTypegtOPEIDlt/SchoolIdTypegt
• 
  ltSchoolIdgt003152lt/SchoolIdgt
• 
  ltSchoolBranchgt00lt/SchoolBranchgt
• 
  ltSchoolNamegtUniversity of Central
  Oklahomalt/SchoolNamegt
• 
  ltInformationSourceIdTypegtOPEIDlt/InformationSourceI
  dTypegt
• 
  ltInformationSourceIdgt824607lt/InformationSourceIdgt

59
Meteor XML Response message 3

• ltLoanInformationgt
• 
  ltLenderIdTypegtOPEIDlt/LenderIdTypegt
• 
  ltLenderIdgt809063lt/LenderIdgt
• ltLenderNamegtBank
  of Oklahomalt/LenderNamegt
• 
  ltSchoolIdTypegtOPEIDlt/SchoolIdTypegt
• 
  ltSchoolIdgt003152lt/SchoolIdgt
• 
  ltSchoolBranchgt00lt/SchoolBranchgt
• 
  ltSchoolNamegtUniversity of Central
  Oklahomalt/SchoolNamegt
• 
  ltInformationSourceIdTypegtOPEIDlt/InformationSourceI
  dTypegt
• 
  ltInformationSourceIdgt809063lt/InformationSourceIdgt
• 
  ltInformationSourceNamegtBank of Oklahomalt/Informati
  onSourceNamegt
• 
  ltInformationSourceDategt2000-11-12lt/InformationSour
  ceDategt
• lt/LoanInformationgt
• ltLoanInformationgt
• 
  ltLenderIdTypegtOPEIDlt/LenderIdTypegt
• 
  ltLenderIdgt831163lt/LenderIdgt
• ltLenderNamegtFirst
  Oklahoma bank amp Trustlt/LenderNamegt
• 
  ltSchoolIdTypegtOPEIDlt/SchoolIdTypegt
• 
  ltSchoolIdgt003152lt/SchoolIdgt

60
uPortal Meteor Channel - Display
61
Meteor branding

• The portal channel (or Website) is branded by the
  data provider
• Information is branded by source
• Logos are used for lender identification

62
What Meteor learned...

• The XML/SOAP business message turnaround is lt 1
  second.
• Because of the scope of authorization for access,
  two separate channels were needed
• Student and parental access to the students
  information
• Financial aid professionals access to information
  about students

63
Authorization
64
Selection
65
Display
66
Versions of the Meteor channel

• 0.7 - Current version support loan lists
• National Student Clearinghouse pilot
• 0.9 - Access to lenders, guaranty agencies
• NSC multiple guaranty agency, lender pilot
• 1.0 - Shared authentication, distributed data
  sources

67
Meteor alternatives
Access Providers
Data Provider
School
Combined Data/Access Provider
Servicer
Student
Guarantee Agency
Lender
68
Pilot implementation
Home Page
Access Provider Website
Student Authentication
National Student
Clearinghouse

• Loan Locator List

National Student

• Loan 1

Clearinghouse

• Loan 2

• Loan 3

PHEAA
Great Lakes
Sallie Mae
69
On the way...

• Meteor initiated convergence to ensure all
  parties would use the same data exchange.
• SFAs Common Record
• Student Loan Industrys CommonLine XML.
• IFX Forums Business Message Specification and
  LoanML.
• SFA will use the SOAP protocol for XML business
  message data transport.
• CommonLine High Performance Channel recommended
  the use of SOAP.

70
On the way...

• Meteor used open source Java SOAP components
  from the Apache Foundation.
• The Meteor software itself was written to the
  current Java 2 specification.
• Meteor demonstrated the software using the JA-SIG
  uPortal with Meteor supplied XSLT transformations.

71
Meteor/NSC Pilot

• Mar - NSC Loan Locator Service
• Apr Loan detail from Sallie Mae, Great Lakes,
  and PHEAA
• May Adding detail data from others that want
  to implement.
• Dan Boehmer, Jan 9, 2000 Meteor Sponsors
  Meeting
• as subsequently amended

72
Meteor implementation
Estimated Date
Priority
March 2001 May 2001 July 2001 July 2001

1. Sponsors
2. Sponsored pilots
3. Schools
4. JA-SIG, general

Schedule based on Sponsor priorities and
selected method of shared authentication
73
Standards and their implementation
Meteor
SFA
Announced Under study Predicted
UML XML Java SOAP XML-RPC UDDI AuthML S2ML
? ? ? ? ? Planned Proposed, with convergence
Feb 2000
74
Impact on Colleges and Universities

• Change
• From Batch to Real-time Transactions,
• From Proprietary File Transfers to Internet XML
  Messaging Standards
• From SFA-defined to Industry Message Content
  Standards
• Integrate Student Experience With SFA
  Student-oriented Systems
• Use Java J2EE Shared-components

75
Electronic IDs
76
E-Signature and promissory note

• Students, parents will choose whose e-signature
  to use
• SFA has no business incentive to share
  e-signature authentication
• Registration is expensive (5 to 50)
  authentication is cheap (0.005 to 0.04)
• Different levels of authentication for different
  purposes
• Paul Tone, Town Hall Meeting on E-Signature, Dec
  14, 2000
• JA-SIG Portal, Meteor will support shared
  authentication using industry standards
• subject to Meteor Sponsor approval

77
To make U2B work we need

• From comments at the NIST Electronic Documents
  Conference, Mar 16, 2000
• Resolution of digital signature requirements
• Beth Grossman, ACCORD
• Legal/ trust/ non- repudiation of electronic
  ID.
• PKI Betsy Fanning, AIIM
• Defining the relationship between PKI
  certificates and signed documents?
• Carol Jacobson

78
Legislative compliance timeline
GPEA
Effective 10/21/03
Effective for FFEL, Perkins and Direct
Loan 06/30/01
E-SIGN
Record retention requirements 6/01/01
Effective 10/01/00
Signed 06/30/00
Signed 10/21/98
79
E-Sign legislation

• To promote e-commerce in private sector
• Legal equivalence between paper and electronic
  documents for binding transactions
• Applies to private sector SFA transactions
  regulated by Federal and State government
• Government to specify standards to ensure
  accuracy, integrity, and accessibility of records
• Requires consent and protection of student
  consumer in electronic context
• Charles Coleman, Town Hall on Electronic
  Identification,Washington, DC, December 14, 2000

80
Shared or remote authentication

• On December 14, 2000, SFA announced that they
  will support authentication of SFA-issued PINS
  and ACES electronic signatures.
• SFA PINs can be used--at a cost--for
  authenticating Title IV transactions.
• SFA plans to honor school, bank, and state agency
  electronic Ids offering comparable or higher
  levels of trust.

However, on January 29, 2001 SFA said they could
not get agreement from the Social Security
Administration to permit others using SFAs PIN
authentication system. Justin E. Tilton, The
Meteor ProjectDestin, Florida, Feb 5, 2001
81
Electronic Identification

• Single Sign On for Students and Financial Aid
  Professionals
• Remote Authentication of Students
• SFA Pin Via Proprietary Protocol
• ACES Digital Certificates Via GSA
• 2002-2004 Plans
• Shared Authentication Using SFA PINs, ACES
  Certificates, School PINs, Bank PINs and
  Certificates
• Town Hall Meeting on Electronic Identification
• December 14, 2000

82

• The Federal Digital Signature Initiative
• General Services Administration

83
The federal ACES initiative

• ACES will facilitate public access to services
  offered by government agencies through use of
  information technologies, including on-line
  access to computers for purposes of reviewing,
  retrieving, providing, and exchanging information
  utilizing e-commerce in a secure transaction
  environment through the use of certificates.
• By law, access to some government computer
  systems can be granted only when the agency is
  provided with assurance that the individual
  attempting access has been properly identified
  and authenticated.
• From /fedcac.gsa.gov/aces.stm, Feb 10, 2001

84
ACES federal digital signatures

• Five categories of Government to Public
  communications have been identified by OMB that
  could require this strong authentication
• Stan Choffrey, GSA/FTS, Dallas,Texas, May 25, 2000

• Application and Transfer of Benefits
• Application and Administration of Grants
• Submission of Reporting or Filing Requirements
• Exchange of Personal/Private/Proprietary
  Information
• Procurement Actions

85
Who Can Use the ACES PKI?

• Any citizen, business entity or governmental
  entity may apply for and be issued ACES
  certificates as subscribers.
• Therefore, non-federal entities may participate
  in ACES in two ways
• As a subscriber to do business with the Federal
  Government, or
• As an authorized Relying Party when duly
  authorized by a Federal Agency for legitimate
  program purposes.
• David Temoshok Access America for Students
  ProgramOffice of Federal Electronic
  CommerceGeneral Services AdministrationApril
  12, 2000

86
Who will have ACES certificates?

• Veterans who receive educational benefits
• Members of the Armed Forces
• Citizens participating in Department of Labor
  employment and training programs

Many college and university applicants and
students will have federally-issued ACES
certificates
87
State initiatives

• Illinois has become the first state to launch a
  comprehensive electronic government initiative.
• Over the next 18 months, we hope to distribute
  over a million digital I.D.s to citizens and
  businesses, to enable them to do business with
  the State as an integrated, secure, web-driven
  government.
• 2001 State of the State, Governor George H.
  Ryan January 31, 2001

88
Digital signature services

• The State of Illinois Public Key Infrastructure
  project (PKI) provides an enterprise-wide
  infrastructure to facilitate electronic
  government services. PKI utilizes public key
  cryptography and digital signatures, along with
  software to manage those certificates. Building
  these services into software applications
  provides the means to authenticate users, ensure
  privacy and integrity of data, and establish the
  audit trails needed to give electronic
  transactions the same or better levels of
  assurance that we are able to provide when we do
  business in paper.
• IL Technology, Oct 2000

89
The Illinois Act protects consumers

• takes into account lack of sophistication and
  technical capabilities of consumers
• provides criminal penalties for forgery of
  digital and electronic signatures
• a signature cannot be automatically attributed to
  a person unless it meets certain stringent
  qualifications
• a secure signature cannot be attributed to a
  consumer, even if he or she was negligent in
  compromising the means by which the signature was
  created, if the signature was not in fact made by
  the consumer.
• Illinois Enacts Groundbreaking
• Electronic Commerce Legislation,Mc Bridge,
  Baker and Coles, Chicago, Illinois, 1998

90
SFA electronic identification

• Single Sign On for Students and Financial Aid
  Professionals
• Remote Authentication of Students
• SFA PIN via Proprietary Protocol
• ACES Digital Certificates via GSA
• 2002-2004 Plans
• Shared Authentication Using SFA PINs, ACES
  Certificates, School PINs, State PINs, and Bank
  PINs and Certificates
• Town Hall Meeting on Electronic
  IdentificationDecember 14, 2000

91
E-Signature and promissory note

• Students and parents will decide whose
  e-signature to use
• SFA has no business incentive to share
  e-signature authentication
• Registration is expensive (5 to 50)
  authentication is cheap (0.005 to 0.04)
• Different levels of authentication for different
  purposes
• Paul ToneTown Hall Meeting on Electronic
  Identification Dec 14, 2000
• JA-SIG Portal, Meteor will support shared
  authentication using industry standards
• recommended to the Meteor Sponsorsby Justin
  Tilton of The Meteor ProjectJA-SIG Conference,
  Feb 5, 2001

92
Legal and policy standards

• Standards for E-Signature
• Digitized Signature
• Digital Certificate
• Digital Document
• Note
• Identifiers
• Personal Identification Number (PIN)
• Other Data
• Retention and Retrieval of Records
• Submission of Records to ED
• E-Signature Implications of the
  E-SIGNLegislation for Student AidElectronic
  Access Conference,
• Phoenix, AZ, Dec 11-12, 2000

93
Questions and answers (lenders)

• Q. If a student refuses E- MPN, how will process
  work?
• A. E- Sign gives the student the option to
  choose. Students and lenders must mutually
  consent to go electronic. Paper options will be
  available.
• Q. Who has the legal responsibility to inform the
  student on rights and responsibilities?
• A. The lender, not the school. The same place as
  they reside today.
• Q. What can be done with SFA PIN vs. the schools
  PIN?
• A. The responsibility of enforcement of the PINs
  certification would be the schools if the school
  PIN is used.
• Questions and Answers fromthe Electronic Access
  ConferencesNov 2000, (documented after the
  conference)

94
Questions and answers (schools)

• Q.Schools may want the ability to confirm the
  validity of a students SFA-PIN number. How can
  this be done by the school?
• A. Security issues would prevent the schools from
  getting the shared secret of the SFA- PIN.
  Authentication is best done by SFA.
• Q. Could a schools PIN number be used for E- MPN
  signing?
• A. Yes, but all other standards must be adhered
  to (supporting documents,verification, security,
  etc.)
• Questions and Answers fromthe Electronic Access
  ConferencesNov 2000, (documented after the
  conference)

95
Requirements for documentation

• 3B. A system should be in place to track password
  usage and changes. Recorded events and
  information should include
• user identifier
• successful and unsuccessful log-ins
• use of password changing procedures
• user ID lock-out record
• date
• time
• physical location
• Trustworthy Information Systems
  HandbookMinnesota State Archives
  DepartmentAug 2000, Sec 9, p. 12

96
Requirements for documentation

• 3C A system should be in place to log and track
  users and their online actions. Audit information
  might include
• details of log-in (date, time, physical location,
  etc.)
• creation of files/records
• accessed file/record identifiers and accompanying
  activity (deletion, modification, change of
  sensitivity/security level)
• accessed device identifiers
• software use
• production of printed output
• overriding of human-readable output markings
• output to storage devices
• Trustworthy Information Systems
  HandbookMinnesota State Archives
  DepartmentAug 2000, Sec 9, p. 12

97
PKI is an economic issue
Number of Users
Unit Cost
Today
Time
98
Colleges and universities should

• Implement the infrastructure for electronic
  identification including digital signatures
• Provide for remote authentication
• Provide a school portal with aggregation
• Develop the procedures for documenting user
  registration and maintenance of electronic
  identifiers
• Provide for a complying electronic record of
  e-commerce activity
• In a standard format for exchange

99
Observations and Recommendations
100
Working Together The Tasks Ahead

• Enabling Real-Time Transaction Processing
• Exchanging Data in Real-Time
• Authentication Knowing Who Our Computers Are
  Doing Business With
• Sharing Lessons Learned and Best Practices

Steve Hawald, Software Developers Conference, Mar
10, 2001
101
Working Together SFAs Role

• Upgrading SFA Systems
• Adopting Mutually Beneficial Data Transport
  Standards
• Developing Technology
• Implementing Policies for Authentication That
  Preserve Privacy and Validate Electronic
  Transactions

Steve Hawald, Software Devlopers Conference, Mar
10, 2001
102
Partnerships

• Open Book Modernization
• Continuing Dialog With the Community
• Open Software Developers Conferences
• SFA Extranet for Community Feedback
• http//extranet.sfa.ed.gov

103
Recommendations to the community

• Invest in the technologies
• XML as used for e-commerce
• Java and Java Server Pages
• Focus on customer behavior and preferences
• 1. Students and parents
• 2. Colleges and universities
• Partner with leaders

104
Standards
105
The endwww.immagic.com