The Mechanics of Electronic Technology _____

1
The Mechanics of Electronic Technology_____

• Tim Bornholtz, FSA
• Michael Sessa, PESC
• Doug Jabbour, ELM Resources
• Matthew Sessa, AES
• Kim Shiflette, USA Funds

2
Welcome and Introductions_____

• Adele Marsh, AES

3
Todays Agenda

• Introduction to Authentication and FSA
• Authentication Standards
• ELM and Authentication
• Pin-less Electronic Signatures
• CRC, DTS and Authentication
• Meteor and Mapping Your Future
• Questions and Wrap-up

4
Introduction to Authentication and FSA
Initiatives_____

• Tim Bornholtz, FSA

5
Terms and Definitions

• Authentication Who is this person?
• Authorization What is this person allowed to
  do?
• Accounting What did this person do while logged
  in to the system?

6
Delegated Administration

• Enables organizations to assign individuals with
  specific security management tasks and duties
• These individuals may be non-IT employees within
  the organization or they may be members of
  partner organizations

7
Transitive Trust

• The practice of accepting a third-party
  identification based on mutual consent between
  two direct parties.
• A trusts B
• B trusts C
• so
• A trusts C

8
Does your workstation look like this?
9
Today
10
Future
11
Why Are We All Working on These Issuesour
Business Reasons
1 Meets customers expectations for simplified
web access 2 Improves the security / privacy of
student aid data with fewer IDs and simpler
management 3 Reduces costs to FSA, schools, etc
12
Moving to Self Service Access
Delegated Administration
Centralized Administration
FSA SYSTEMS
School B
School A
School B
School A
13
Transitive Trust / Federated Identity
1 Transitive Trust and Federated Identitythe
practice of accepting a third-party identity
based on mutual consent between two direct
parties.
3 FSA does not plan to be a leader in this
spacewe will participate
14
In Summary FSA is
1 moving forward with the Access Management
Team. 2 testing Tivoli Identity Manager (TIM)
and Tivoli Access Manager (TAM) as security
products. 3 moving toward a Delegated
Administration model. 4 participating in the
Transitive Trust discussionsnot leading.
15
Questions?

• Tim Bornholtz
• tim.bornholtz_at_ed.gov
• Phone [phone]

16
Authentication Standards_____

• Michael Sessa, PESC

17
PESCs Role

• Track and communicate current events and
  happenings
• Educate community on issues
• Facilitate identification of business problems
  and potential solutions
• Promote best practices, prototypes, reference
  implementations, and community progression
• Collaborate with influential organizations
  (Federal Government, EAP, Liberty Alliance,
  Internet 2)

18
Federal Government

• The Federal Perspective www.CIO.gov/eAuthenticatio
  n
• OMB Guidance December 16, 2003 (M-0404) for
  Government Paperwork Elimination Act of 1998 and
  E-Government Act.
• Assists agencies in determining their
  authentication needs for electronic transactions.
• Directs agencies to conduct e-authentication risk
  assessments on electronic transactions to ensure
  that there is a consistent approach across
  government.
• Provides the public with clearly understood
  criteria for access to Federal government
  services online.

19
Federal Government
Four Assurance Levels Level 1 Little or no
confidence in the asserted identitys
validity. Level 2 Some confidence in the asserted
identitys validity. Level 3 High confidence in
the asserted identitys validity. Level 4 Very
high confidence in the asserted identitys
validity.
20
Federal Government

• NIST Special Publication 800-63 January 2004
  states specific technical requirements for each
  of the four levels of assurance
• Identity proofing, registration, and delivery of
  credentials.
• Tokens for proving identity.
• Remote authentication mechanisms (credentials,
  tokens, and protocols used to establish that a
  claimant is in fact the subscriber claimed to
  be).
• Assertion mechanisms used to communicate the
  results of a remote authentication to other
  parties.

21
Federal Government

• Burton Group Report
• An independent program review of technical
  architecture, interoperability, and trust
  characteristics
• EAP
• Available through www.CIO.gov/eAuthentication

22
EAP

• EAP www.EAPartnership.com
• Formed by CSIS, OMB, and GSA.
• EAP is the multi-industry partnership working on
  the vital task of enabling interoperability among
  public and private electronic authentication
  systems.
• Goal is to create a free-standing non-profit
  organization that will manage Authentication
  similarly to how the networks for direct deposit
  and ATMs are managed.
• Bylaws finalized September 2004.
• Business Rules and Processes October 2004.
• Interoperability Report October 2004.

23

EAP
EAP Governance
Technical Interoperability
Accreditation Certification
Credential Assessment Criteria
Business Rules Processes
Assurance Levels

• Standards Body?
• Federated Infrastructure Provider?
• Both?

24
Liberty Alliance

• Liberty Alliance www.ProjectLiberty.org
• Formed 9/2001, led by Sun Microsystems, and
  includes American Express, Computer Associates,
  GM, HP, Nokia, Novell, PingID, RSA Security, SAP,
  Vodafone, IBM, Adobe, AOL, Fidelity, Intel, Bank
  of America, Deloitte Touche, Oracle, Sony,
  Verisign, US Department of Defense, US GSA, and
  others (150 total)
• Goal is to establish an open standard for
  federated network identity by developing
  technical specifications that support a broad
  range of identity-based products and network
  devices.

25
Liberty Alliance

• Vision is to enable a networked world in which
  individuals and businesses can more easily
  conduct transactions while protecting the privacy
  and security of identity information to create
  the flexible, secure and open infrastructure that
  is required to support and manage these online
  services and transactions.
• Includes specifications, conformance and
  certification, product endorsement

26
Internet 2

• Internet 2 www.Internet2.edu
• Shibboleth http//shibboleth.internet2.edu
• Launched 2/2000, it is an initiative to develop
  an open, standards-based solution to meet the
  needs for organizations to exchange information
  about their users in a secure, and
  privacy-preserving manner. The initiative is
  facilitated by Internet2 and a group of leading
  campus middleware architects from member schools
  and corporate partners.
• The purpose of the exchange is typically to
  determine if a person using a web browser has the
  permissions to access a resource at a target
  resource based on information such as being a
  member of an institution or a particular class.

27
Questions?

• Michael Sessa
• sessa_at_pesc.org
• [phone]

28
ELM and Authentication_____

• Doug Jabbour, ELM Resources

29
What is ELM Resources?

• Mutual benefit corporation
• Alliance of lenders, guarantors, and servicers
• Cooperative venture, open to all
• Non-profit company
• Provider neutral
• Free services to schools
• Single point of data exchange
• Technology bridge

30
ELM Is Open

• ELM members represent over 90 of FFEL volume
• All guarantors interfaced
• Provider neutral
• 1,200 schools using ELM
• Choice of lenders, guarantors, servicers
• Choice of providers based on service
• Control over loan process
• Supports all standard application flows

31
What Does ELM Do?

• Loan delivery
• Central database
• Reports
• Inquiries
• National disbursement service

32
(No Transcript)
33
ELM NDN

• ELM NDN participants
• 982 schools for disbursements
• 272 schools use refund automation
• In 2003
• 3.65 million disbursements
• 7.9 billion - 44 v 2003
• In 2004
• Volume up approx. 40 YTD
• Est. 11 Billion

34
ELM Growth In 10 Years
35
ELM User Access

• Schools 5,372
• Lenders 1,386
• Guarantors 200
• Borrowers 110,060

36
(No Transcript)
37
ELM User Authentication

• Primary ELM focus is authentication for loan
  processing
• 1,200 plus schools 5,300 authorized school
  users
• School users are authorized to
• Inquire
• Update
• Exchange files

38
ELM User Authentication

• Each school has an ELM-recognized security person
• This person authorizes each user at that school
• This person is responsible for notifying ELM of
  staff changes

39
ELM Security Enhancements

• Increasing the strength of the ELM password
• Size, construction
• Only the user knows the password
• Self-service password resets
• Reset every 90 days or sooner

40
ELM User Authentication

• Future focus will be on students accessing ELMNet
  via the school SIS
• Behinds the scenes access to lenders, servicers,
  and guarantors
• Reliance upon the School for identification and
  authentication
• Schools are already moving in this direction

41
ELM Authentication Issues

• Competing Demands
• Ease of use
• Privacy
• Security
• Accountability
• Federal Laws
• State Laws

42
ELM Authentication Issues

• Diversity of ELM Members
• Federally Chartered Banks
• Credit Unions
• Guarantors
• Servicers
• Schools

43
ELM Authentication Issues

• Diversity of Schools
• Large schools with sophisticated SIS
• Medium size schools
• Relatively small schools
• Schools that want to control all student/borrower
  contact
• Schools that want ELM or ELM Members to interact
  with the student/borrower

44
ELMNet Going Forward

• Looking to industry standards
• Looking to technology changes
• Trying to meet competing demands
• Ease of use
• Security and privacy
• Regulatory
• Federal and state laws

45
How Do We work On It?

• Work with our Members
• School user meetings
• School Advisory Council
• National efforts
• NCHELP
• PESC
• CBA

46
Questions?

• Doug Jabbour
• djabbour_at_elmresources.com

47
Pin-less Authentication_____

• Matthew Sessa, AES

48
Agenda

• Emergence of Authentication Choices
• PIN vs. PINless
• On the horizon
• The role of standards

49
Todays Choices

• PIN
• Student Authentication Network (STAN)
• PINless
• Credit Vendor
• Data match
• Out-of-wallet
• First Party plus school certification

50
Decisions, decisions...

• STAN
• Right
• STAFFORD, Perkins, sometime PLUS and
  Consolidation
• Not Right
• State Grants, Alternative, sometimes PLUS and
  Consolidation

51
Decisions, decisions

• PINless - Data match with credit vendor
• Right
• No federal affiliation, relatively low-risk form
• Not Right
• High risk forms
• PINless - Out-of-wallet with credit vendor
• Right
• No federal affiliation, older demographic, high
  risk
• Not right
• young demographic and/or low risk

52
AES has decided to offer the consumer part of the
choice

• AES will present choices based on risk and cost,
  among other variables, including lender
  participation
• STAN where it makes sense and where it is
  permitted
• PINless if STAN is prohibited or consumer does
  not have PIN
• Where both authentication solutions are
  appropriate, the consumer will have a choice

53
Issues arising from offering choices

• Need to track the authentication method used for
  each electronic signature
• Counsel will have to defend multiple
  authentication processes
• Interoperability

54
Why choices are necessary today

• STAN has built in restrictions
• Managing cost
• Even first party authentication and school
  certification does not work where the borrower is
  not certified (i.e. PLUS and some alternative
  loans)

55
Questions?

• Matthew Sessa
• msessa_at_aessuccess.org
• [phone]

56
Common Record CommonLine, Data Transport
Standard and Authentication_____

• Kim Shiflette, USA Funds

57
Session Objectives

• CRC Overview
• Convergence/Benefits
• Key Differences from CommonLine
• CRC Process
• Whats the same, Whats new
• Implementation Schedules
• Reference Information
• DTS Overview

58
CRC Defined

• Common Record CommonLine (CRC)
• The new XML-based electronic data exchange
  standard for FFELP and alternative loan
  origination and disbursement processing
• XML - In ordinary English, definitions related to
  Schema include
• A diagrammatic presentation
• The disposition of constituents in a pattern or
  according to a scheme
• A scheme or systematic arrangement
• XML terms describe and constrain the content and
  sequence of content of XML documents

59
Convergence Historical Perspective

• FFELP was pursuing implementation of CommonLine
  5.0 - Flat and XML
• At the same time SIS and FAMS vendors were
  implementing FSAs new COD Common Record XML
  requirements
• Collaboration
• Created a Common Data Dictionary across higher
  education
• Developed similar XML schemas
• Similar processing concepts where appropriate and
  possible

60
Benefits of XML and CRC

• Allows schools to use one Record structure
  between disparate databases or different systems
• COD, CL, Meteor, Transcripts, etc.
• designed to meet the needs of the Schools and
  FAMS Vendors
• Converts Change Processes from Transaction-based
  to End Result-based
• Streamlines Application and Disbursement
  Processes
• support batch and real-time data exchange
• XML lets you send only the data needed for the
  process being performed
• Converts Change Processes from Transaction-based
  to End Result-based

61
Collaborative Business Requirements

• Reengineering required collaboration between
  organizations FSA, NCHELP, PESC - Outcome
• Maintain current CommonLine 5 functionality
• Maintain flexibility of FFELP processing for our
  School customers
• Emulate CRCOD where applicable - structure,
  process and naming convention
• Create a cross-industry data dictionary

62
CRC Key Differences

• New formats, new names
• Loan Period Begin and End dates are now referred
  to as ltFinancialAwardBeginDategt and
  ltFinancialAwardEndDategt
• Words are used when possible to represent
  information. For example, US Citizen value (1) is
  now Citizen
• One student - multiple requests in same document
  Originate, Change, etc.
• Records sorted by attending school
• Support School Assigned ID for student and or
  borrower

63
CRC Document Structure
64
CRC XML Structure

• ltCommonRecordgt
• ltDocumentInformationgtlt/DocumentInformationgt
• ltAttendedSchoolgt
• ltStudentgt
• ltLoangtlt/Loangt
• ltAwardgtlt/Awardgt
• ltDisbursementgtlt/Disbursementgt
• lt/Studentgt
• lt/AttendedSchoolgt
• lt/CommonRecordgt

65
CRC Supported Processes

• Loan Requests
• Loan Reprint Requests
• Loan Termination Requests
• Loan Certification Requests
• Pre-guarantee Correction Requests
• Post-guarantee Change Requests
• Response Processing
• Disbursement Processing

66
CRC Fun Facts

• Disbursement Day Override Indicator
• Ability to pass Credit Status data
• Minimal data for Pre-guarantee Corrections,
  Reprint and Terminates
• Only send corrected/changed data
• Disbursement Amounts can be passed for Stafford
  and PLUS requests
• New Response Formats and indicator
• Snapshot - everything
• Full what was sent
• Standard only indicates accept or reject

67
Documentation

• CRC Implementation Guide 1.05 October 2004
• Rule, Layout, Examples, crosswalks
• Schema 1.01 October 2004
• Instance documents and structure
• Testing Tool 1.05 October 2004
• Verifies format, content and provide cross field
  validation
• Registry and Repository October 2004
• Schema and data element storage and management

68
Implementation Schedule

• FAMS
• All are in various stages of analysis
• forecasting production implementations between
  Fall 04 and Spring 05.
• Sigma is looking for testing partners in Summer
  04.
• Stay in touch with your Vender
• HGS access documentation
• Service Providers
• planning schedules parallel to the vendor
  timelines.
• Phased and full implementation
• Most looking at spring 05

69
Information Sources

• NCHELP - The CRC Implementation Guide is
  available at www.nchelp.org
• IFAP COD news, technical documentation,
  updates, etc. at www.ifap.ed.gov
• PESC XML Technical Specifications, Data
  Dictionaries, Schemas, assistance and approvals,
  etc. at www.pesc.org
• Additional training TBD for 2005

70
DTS - Data Transport Standard - A Standard for
Transmitting Data

• Chapter 1 In the beginning
• Need
• Vision and Collaboration
• Chapter 2 Getting there.
• Direction
• Requirements
• Chapter 3 Build it and they will come.
• Process
• Flow
• Potential Uses
• Chapter 4 Make it happen ....
• Workgroup structure and responsibility
• Implementation

71
Chapter 1, In the beginning
72
Need

• The concept of DTS began in 2003, when NCHELP
  recognized a need to develop a transport process
  to support the CRC initiative.
• Specifically,
• real-time requests - no existing standard
• batched requests larger payloads w/ XML
  format
• consolidate support fewer exchange methods
• improve key management, guaranteed delivery,
  etc.
• single solution - new exchange participants

73
DTS Vision and Collaboration

• Vision - A single standard for the real-time
  transport to support
• any data, any business process, any process
  expectation (immediate, deferred, other),
• any system and any time
• Collaboration - NCHELP members requested DTS be
  developed in a collaborative manner
• FSA, schools, lenders, guarantors and Financial
  Aid Management System vendors
• Representing various business sectors of the
  higher education industry FFEL, DL, Admissions
  and Registrars, MYF, Meteor, etc.

74
Chapter 2, Getting there
Did she say something
Did I turn the stove off?
DTS is a standard...
Our first Industry Meeting
75
Direction and Requirements

• Created Business team to evalulate
• the feasibility for a new standard,
• defined existing transport issues,
• defined business requirements
• and reviewed proposed transport options.
• Business Requirements
• Secure Data Transport and guaranteed Delivery
• Support payload types (routing) and process
  expectations (immediate or deferred)
• Support any Business Process
• Ensure Cost and Technology not a barrier to
  adoption or use, Utilize Open Standards
• Support Interoperability between disparite
  systems- Computing Platform Independent

76
Chapter 3 Build it and they will come.
77
DTS Process

• DTS is a web service
• Client Backend System creates and processes
  message/data to and from the DTS Client
• DTS Client interfaces with client backend
  system and DTS service to send/retrieve secure
  message/data to and from the DTS Service
• DTS Service verifies message/data is secure and
  well formed from DTS client or DTS application
• DTS Application interfaces with the DTS Service
  and existing backend systems to send and respond
  to message/data
• A Backend System (s) creates, processes and or
  generates message/data for the DTS application

78
DTS Process Flow

• DTS Message DTS DTS Back
  End
• Client Data Service Application
  System

Retrieve Interface Return
soap
Edit Acknowledge
Process return
Send Receive
soap
79
DTS Potential Uses

• Deliver data only
• Immediate request immediate response
• Immediate request deferred response
• Deferred request - no immediate response
• Retrieve response for a specific deferred request
• Retrieve data

80
Chapter 4 Make it happen ....

• Position Project to Succeed
• Industry Workgroup
• Industry Stakeholders
• Industry Solution

81
PESC Workgroup Structure

• DTS Project - moved to PESC
• Chairperson Project oversight
• Community Spokesperson
• DTS Business Workgroup
• Identify stakeholders and requirements
• Oversight and approval for technical solutions
• DTS Technical Workgroup
• Develop technical solution, documentation, etc.

82
Implementation, Documentation, Calls and Meetings

• Implementation
• Beta January 05
• Spring 05
• Web Site
• http//committees.nchelp.org/esc/eeat/default.aspx
  
• Select Data Transport Standard Project folder
• Working documents specs, project plans, process
  flows, etc.
• Technical Workgroup
• meets Tuesdays, at 1100 a.m. EST, and Thursday,
  at 200 p.m. EST
• Future Meetings
• EAC Las Vegas
• Additional workgroup meeting TBD

83
Questions?

• Kim Shiflette
• kshiflet_at_usafunds.org
• [phone]

84
Meteor and Mapping Your Future_____

• Adele Marsh, AES

85
The Meteor Process
Access Providers
Data Providers
One
Financial Aid Professional or Student
Two
Index Providers
Three
86
Enhancements

• NSC Loan locator is used to display the location
  of the borrowers loans
• Aggregate loan limit/underlying consolidation
  loans
• Consolidation Loans can be reported as
  Subsidized, Unsubsidized, HEAL and Other

87
Default Aversion Ideas

• Collaborations with Mapping Your Future
• Allow Skip-tracing staff to view contact
  information from all providers (if they have a
  relationship with the borrower)
• Late Stage Delinquency Information

88
Mapping Your Future

• Mapping Your Future is a public-service web site
  (http//mapping-your-future.org) providing
  career, college, financial aid, and financial
  literacy information and services.

89
Collaboration Discussion

• Mapping Your Future Meteor are collaborative
  projects of the financial aid industry, both
  with primary missions of serving schools,
  students families. Sponsors volunteers of
  both have expressed an interest in collaboration
  between the two groups.

90
Benefits of Projects

• Strengthens Meteor Mapping Your Futures
  ability to provide financial aid information
  services
• Access OSLC Meteor data with one login
• Students receive loan information counseling in
  one web visit, regardless of loan holder or
  guarantor

91
Benefits of Projects

• Default prevention
• Help schools meet regulatory requirement to
  provide estimated repayment information
• Provide more accurate up-to-date information to
  students

92
Proposed Projects

• Meteor school access
• Display Meteor data for students completing OSLC
• Pre-fill or display Meteor data for entry into
  calculators

93
Comparison Calculators

• MYF developing two calculators
• Demonstrate effects of various repayment plans
• Demonstrate interest capitalization
• Pre-fill or display Meteor data for entry into
  calculators

94
Questions?

• Adele Marsh, AES
• amarsh_at_aessuccess.org
• 717-720-2711

95
Thank you for joining us!Please be sure to
complete your conference evaluation form!

• Tim Bornholtz, FSA
• Michael Sessa, PESC
• Doug Jabbour, ELM Resources
• Matthew Sessa, AES
• Kim Shiflette, USA Funds