ࡱ>  mbjbj 4hhe? 99999MMM8tMQ$1(YYY,FQHQHQHQHQHQHQSVHQ9G#^G#G#HQ99YYF]Q:&&&G#9Y9YFQ&G#FQ&&RI9NYxbM5$LM2QQ<QjM>+W%H+W<NN+W9zO &-!t!HQHQM&pQG#G#G#G#+W : Oregon State University eSignature Policy Effective June 30, 2008 Last Revised June 30, 2008 Who Should Read This Policy Administrators for OSU entities which have or will be implementing electronic signature for conducting OSU business should read and be familiar with this policy. Introduction & Definitions Policy Statement eSignature Evaluation Process Approval, Implementation, and Maintenance Authority Samples Resources Introductory Material Background The Electronic Signatures Act (Public Law No: 106-229) went into effect on October 1, 2000 and gives electronic contracts the same weight as those executed on paper. The act has some specific exemptions or preemptions. Although the act enables documents to be signed electronically, the option to do so lies solely with the consumer. The act specifically avoids stipulating any 'approved' form of electronic signature, instead leaving the method open to interpretation by the marketplace. Any number of methods is acceptable under the act. Methods include simply pressing an I Accept button, digital certificates, smart cards and biometrics. E-signatures may be implemented using various methodologies depending on the risks associated with the transaction. Examples of transaction risks include: fraud, non-repudiation, and financial loss. The quality and security of the e-signature method should be commensurate with the risk and needed assurance of the authenticity of the signer. Authentication is a way to ensure that the user who attempts to perform the function of an electronic signature is in fact who they say they are and is authorized to sign. Definitions. For the purposes of this policy: AUTHENITICATION- To establish as genuine and verify of the identity of a person providing an electronic signature. CREDENTIAL- an object that is verified when presented to the verifier in an authentic transaction. ELECTRONIC RECORD- A contract or other record created, generated, sent, communicated, received, or stored by electronic means. ELECTRONIC SIGNATURE- An electronic signature/approval (e-signature) is defined as an electronic identifier that is created by a computer and is intended by the party using it to have the same intent, affect and authority as the use of a manual (either written or facsimile) signature. TRANSACTION- A discrete event between a user and system that supports a business or programmatic purpose. Policy Statement The intent of this policy is to allow for e-signature use at OSU by means of methods that are practical, secure, and balance risk and cost. It is not the intent of this policy to eliminate all risk but rather to provide a process that gives parties assurance appropriate analysis was completed prior to implementation of e-signature, and that the that the level of user authentication used is reasonable for the type of transaction conducted. The E-Authentication Guidance for Federal Agencies, OMB 04-04 (see Reference 9.1) defines four levels of assurance, Levels 1 to 4, in terms of the consequences of authentication errors and misuse of credentials. The guidance defines the required level of authentication assurance in terms of the likely consequences of an authentication error. The e-Authentication Risk and Requirements Assessment (eRA) tool is the risk and assurance level evaluation tool to be used at OSU (see Reference 9.2). User authentication entails verifying the users unique credentials: such as username and password, or a digital certificate. This may requires validation against specific OSU held information. Security and access to OSU-specific information is determined by a record custodian. Record custodians are responsible for compliance with all legal obligations related to information, and in that capacity have final authority for the utilization, access, and release of data under their jurisdiction. In some instances there are multiple custodians for various sets of data. Under this policy, a University entity may implement use of e-signatures. A University entity, or Unit, is the OSU organization conducting business by means of an e-signature; such as a College, department, auxiliary, or administrative division. Any University transaction enabled by e-signatures must be evaluated by the Unit in conjunction with the applicable records custodian, using the eRA tool. (This includes any existing implied or explicit e-signatures in use prior to the adoption of this policy.) For risk assessment and review purposes, similar types of transactions may be grouped together under one agreement. Implemented e-signatures will be reviewed periodically for appropriateness, and continued applicability. An e-signature may be accepted in all situations if requirement of a signature/approval is stated or implied. This policy does not supersede situations where laws specifically require a written signature. This policy cannot limit the right or option to conduct the transaction on paper or in non-electronic form and the right to have documents provided or made available on paper at no charge. The e-signature must be protected by reasonable security measures as applicable to established computer functions of the University Evaluation Process for Use of Electronic Signature Evaluation of Risk An evaluation will be performed by the Unit to determine risks associated with using an e-signature and to determine the quality and security of the e-signature method required. An evaluation will be made using the E-Authentication Guidance for Federal Agencies, OMB 04-04 (Reference 9.1) for reference and guidance. The e-RA tool will assist Units determine the level of risk. The reports resulting from the eRA assessment shall be included as part of the official record for this e-signature implementation and submitted with the proposal to the records custodian. Determination of Electronic Signature Methodology The e-signature methodology should be commensurate to the assurances needed for the risks identified. In addition, specifications for recording, documenting, and/or auditing the e-signature as required for non-repudiation and other legal requirements shall also be determined by the Unit. The lowest cost, least complex method acceptable for the risk is generally preferable. The National Institute of Standards and Technology (NIST) Electronic Authentication Guidelines publication (see Reference 9.5) can be useful in making this determination. Units that propose e-signature methods that are at a higher or lower level of assurance than indicated in the risk assessment process shall: Describe the reason for variance. Identify the potential risk of using a tool from a lower (or higher) assurance level than the risk assessment identifies. Identify the steps that will be taken to mitigate the risk or justify why a higher assurance level method is appropriate. Obtain the signed approval of the Unit director. The signed document shall be included as part of the official record for this e-signature implementation. Approval The Unit will seek approval to implement an e-signature from the applicable records custodian. It is the records custodians responsibility to ensure that the proposed e-signature and method meet the requirements of this policy. In determining whether to approve an e-signature method, consideration will be given to the systems and procedures associated with using that electronic signature, and whether the use of the electronic signature is at least as reliable as the existing method being used. Should it be deemed necessary by the records custodian, he/she will seek approval from University Legal Counsel and the appropriate information technology office or officer, such as the Chief Information Security Officer (CISO). Implementation. The implementation process will likely differ for each transaction and for each Unit, as it is dependent on many factors such as technical environment, appropriate assurance level, and the nature of the transaction. Maintenance and Review Requirements Recordkeeping. A formal record of the risk assessment evaluation, e-signature method selection, and justification will be maintained by the Unit. At such time as the University has implemented a technology security plan and infrastructure, a copy would also be filed at the office of the CISO. Security. Software and/or hardware that are required for e-signatures, such as Public Key Infrastructure (PKI) certificates, fobs, or dongles, will be provided by the Unit. The Unit will also ensure that appropriate controls and monitoring of the software/hardware are in place. Periodic Review A review of each e-signature implementation will be conducted periodically, but no less that every three years, by the Unit. This will include an evaluation of the e-signature use to determine whether any applicable legal, business, or data requirements have changed. A determination will be made as to the continued appropriateness of the risk assessment and e-signature implementation method. A record of this review will be documented and filed as part of the official record for this e-signature implementation maintained by the Unit. If as a result of the periodic review the risk level changes, a new risk assessment must be completed, including review and approval. Authority. Various Federal rules and regulations establish the authority for use of electronic signatures. The Electronic Signatures in Global and National Commerce Act enacted on June 30, 2000 (S761, HR 1320 IH, commonly known as the ESIGN.) established the validity of electronic records and signatures. The Uniform Electronic Transactions Act (UETA) provides a legal framework for electronic transactions. It gives electronic signatures and records the same validity and enforceability as manual signatures and paper-based transactions. UETA was adopted by Oregon in 2001 and created legal recognition for most electronic transactions and parallels the legal recognition for paper transactions conducted in Oregon. (Uniform Electronic Transactions Act Chapter 84 (HB 2112) and OAR 125-600-0000.) Sample Forms and Exhibits Attachment A. Sample Proposal/Request Form Attachment B. Excerpts from eRA Tool Activity Guide, multiple versions Attachment C. Excerpts from M04-04: E-Authentication Guidance for Federal Agencies Resources and Links E-authentication Guidance for Federal Agencies: OMB M04-04;  HYPERLINK "http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf" http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf e-RA (Risk Assessment) Tool:  HYPERLINK "http://www.cio.gov/eauthentication/era.htm" http://www.cio.gov/eauthentication/era.htm Electronic Signatures in Global and National Commerce Act (ESIGN):  HYPERLINK "http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=106_cong_public_laws&docid=f:publ229.106.pdf" http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=106_cong_public_laws&docid=f:publ229.106.pdf Family Educational Rights and Privacy Act (FERPA): 34 CFE Part 99; Final These final regulations provide general guidelines for accepting signed and dated written consent under FERPA in electronic format;  HYPERLINK "http://www.ed.gov/legislation/FedRegister/finrule/2004-2/042104a.pdf" http://www.ed.gov/legislation/FedRegister/finrule/2004-2/042104a.pdf NIST Electronic Authentication Guidelines: 800-63;  HYPERLINK "http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf" http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf Oregon Revised Statutes Chapter 84 Electronic Transactions (UETA):  HYPERLINK "http://www.leg.state.or.us/ors/084.html" http://www.leg.state.or.us/ors/084.html OSU Acceptable Use of University Information Policy  HYPERLINK "http://oregonstate.edu/dept/budgets/genupol/gupaccep2.htm" http://oregonstate.edu/dept/budgets/genupol/gupaccep2.htm Standards for Electronic Signatures in Electronic Student Loan Transactions:  HYPERLINK "http://www.ifap.ed.gov/dpcletters/attachments/gen0106Arevised.pdf" http://www.ifap.ed.gov/dpcletters/attachments/gen0106Arevised.pdf ATTACHMENT A SAMPLE FORM Proposal for Use of eSignature Requesting Unit: _______________________________________________________________ Electronic Transaction Description: ________________________________________________ Attach results of e-Authentication Risk and Requirements Assessment (eRA reports) for specific transaction(s). Application Detail Report Application Information Report Application Risk Tolerance Criteria Report Transaction Summary Report Risk Identification Report Risk Analysis Report Transaction Level Summary Report User Role Level Summary Report Issues Report Describe electronic authentication method for this transaction: Describe how the electronic authentication method meets the risks of the Potential Impact/Assurance identified: Describe any data integrity, audit, or archive requirements for this transaction, and how they will be met: Describe any security or access control requirements, and how they will be met: OSU Unit Proposer Signature & Date: ___________________________________________ OSU Records Custodian Remarks (approved/disapproved) OSU Records Custodian Signature & Date: _______________________________________ OSU Legal Council Signature & Date (if required/requested): ______________________________ OSU CISO or IT Representative Signature & Date: ______________________________________ ATTACHMENT B EXCERPT FROM: eRA Tool Activity Guide, multiple versions OMB Authentication Guidance This guidance is provided in e-Authentication Guidance for Federal Agencies and includes specific definitions for four authentication levels, based on the potential risks and impact of unauthorized use of electronic transaction. For convenience, the authentication levels as defined by this OMB guidance are provided below. Level 1 Definition: Little or no confidence exists in the asserted identity. For example, Level 1 credentials allow people to bookmark items on a web page for future reference. Examples In some instances, the submission of forms by individuals in an electronic transaction will be a Level 1 transaction: o when all information is flowing to the Federal organization from the individual o there is no release of information in return o the criteria for higher assurance levels are not triggered For example, if an individual applies to a Federal agency for an annual park visitors permit (and the financial aspects of the transaction are handles by a separate contractor and thus analyzed as a separate transaction), the transaction with the Federal agency would otherwise present minimal risks and could be treated as Level 1. A user presents a self-registered user ID or password to the U.S. Department of Education web page, which allows the user to create a customized My.ED.gov page. A third party gaining unauthorized access to the ID or password might infer personal or business information about the individual based upon the customization, but absent a high degree of customization however, these risks are probably very minimal. A user participates in an online discussion on the whitehouse.gov website which does not request identifying information beyond name and location. Assuming the forum does not address sensitive or private information, there are no obvious inherent risks. Level 2 Definition: On balance, confidence exists that the asserted identity is accurate. Level 2 credentials are appropriate for a wide range of business with the public where agencies require an initial identity assertion (the details of which are verified independently prior to any Federal action). Examples A user subscribes to the Gov Online Learning Center (www.golearn.gov). The sites training service must authenticate the person to present the appropriate course material, assign grades, or demonstrate that the user has satisfied compensation-or promotion-related training requirements. The only risk associated with this transaction is a third party gaining access to grading information, thereby harming the students privacy or reputation. If the agency determines that such harm is minor, the transaction is Level 2. A beneficiary changes her address of record through the Social Security web site. The site needs authentication to ensure that the entitled persons address is changed. This transaction involves a low risk of inconvenience. Since official notices regarding payment amounts, account status, and records of changes are sent to the beneficiarys address of record, it entails moderate risk of unauthorized release of personally sensitive data. The agency determines that the risk of unauthorized release merits Assurance Level 2 authentication. An agency program client updates bank account, program eligibility, or payment information. Loss or delay would significantly impact him or her. Errors of this sort might delay payment to the user, but would not normally result in permanent loss. The potential individual financial impact to the agency is low, but the possible aggregate is moderate. An agency employee has access to potentially sensitive personal client information. She authenticates individually to the system at Level 2, but technical controls (such as a virtual private network) limit system access to the system to the agency premises. Access to the premises is controlled, and the system logs her access instances. In a less constrained environment, her access to personal sensitive information would create moderate potential impact for unauthorized release, but the systems security measures reduce the overall risk to low. Level 3 Definition: Level 3 is appropriate for transactions needing high confidence in the asserted identitys accuracy. People may use Level 3 credentials to access restricted web services without the need for additional identity assertion controls. Examples A patent attorney electronically submits confidential patent information to the US Patent and Trademark Office. Improper disclosure would give competitors a competitive advantage. A supplier maintains an account with a General Services Administration Contracting Officer for a large government procurement. The potential financial loss is significant, but not severe or catastrophic, so Level 4 is not appropriate. A First Responder accesses a disaster management reporting website to report an incident, share operational information, and coordinate response activities. An agency employee or contractor uses a remote system giving him access to potentially sensitive personal client information. He works in a restricted-access Federal office building. This limits physical access to his computer, but system transactions occur over the Internet. The sensitive personal information available to him creates a moderate potential impact for unauthorized release. Level 4 Definition: Level 4 is appropriate for transactions needing very high confidence in the asserted identitys accuracy. Users may present Level 4 credentials to assert identity and gain access to highly restricted web resources, without the need for further identity assertion controls. Examples A law enforcement official accesses a law enforcement database containing criminal records. Unauthorized access could raise privacy issues and/or compromise investigations. A Department of Veterans Affairs pharmacist dispenses a controlled drug. She would need full assurance that a qualified doctor prescribed it. She is criminally liable for any failure to validate the prescription and dispense the correct drug in the prescribed amount. An agency investigator uses a remote system giving her access to potentially sensitive personal client information. Using her laptop at client worksites, personal residences, and businesses, she accesses information over the Internet via various connections. The sensitive personal information she can access creates only a moderate potential impact for unauthorized release, but her laptops vulnerability and her non-secure Internet access raise the overall risk. ATTACHMENT C EXERPT FROM: M-04-04: E-Authentication Guidance for Federal Agencies Potential Impact Categories: To determine the appropriate level of assurance in the users asserted identity, agencies must assess the potential risks, and identify measures to minimize their impact. Authentication errors with potentially worse consequences require higher levels of assurance. Business process, policy, and technology may help reduce risk. The risk from an authentication error is a function of two factors: a) potential harm or impact, and b) the likelihood of such harm or impact. Categories of harm and impact include: Inconvenience, distress, or damage to standing or reputation Financial loss or agency liability Harm to agency programs or public interests Unauthorized release of sensitive information Personal safety Civil or criminal violations. Required assurance levels for electronic transactions are determined by assessing the potential impact of each of the above categories using the potential impact values described in Federal Information Processing Standard (FIPS) 199, Standards for Security Categorization of Federal Information and Information Systems. The three potential impact values are:6 Low impact Moderate impact High impact. Determining Potential Impact of Authentication Errors: Potential impact of inconvenience, distress, or damage to standing or reputation: Lowat worst, limited, short-term inconvenience, distress or embarrassment to any party. Moderateat worst, serious short term or limited long-term inconvenience, distress or damage to the standing or reputation of any party. Highsevere or serious long-term inconvenience, distress or damage to the standing or reputation of any party (ordinarily reserved for situations with particularly severe effects or which affect many individuals). Potential impact of financial loss: Lowat worst, an insignificant or inconsequential unrecoverable financial loss to any party, or at worst, an insignificant or inconsequential agency liability. Moderateat worst, a serious unrecoverable financial loss to any party, or a serious agency liability. Highsevere or catastrophic unrecoverable financial loss to any party; or severe or catastrophic agency liability. Potential impact of harm to agency programs or public interests: Lowat worst, a limited adverse effect on organizational operations or assets, or public interests. Examples of limited adverse effects are: (i) mission capability degradation to the extent and duration that the organization is able to perform its primary functions with noticeably reduced effectiveness, or (ii) minor damage to organizational assets or public interests. Moderateat worst, a serious adverse effect on organizational operations or assets, or public interests. Examples of serious adverse effects are: (i) significant mission capability degradation to the extent and duration that the organization is able to perform its primary functions with significantly reduced effectiveness; or (ii) significant damage to organizational assets or public interests. Higha severe or catastrophic adverse effect on organizational operations or assets, or public interests. Examples of severe or catastrophic effects are: (i) severe mission capability degradation or loss of to the extent and duration that the organization is unable to perform one or more of its primary functions; or (ii) major damage to organizational assets or public interests. Potential impact of unauthorized release of sensitive information: Lowat worst, a limited release of personal, U.S. government sensitive, or commercially sensitive information to unauthorized parties resulting in a loss of confidentiality with a low impact as defined in FIPS PUB 199. Moderateat worst, a release of personal, U.S. government sensitive, or commercially sensitive information to unauthorized parties resulting in loss of confidentiality with a moderate impact as defined in FIPS PUB 199. Higha release of personal, U.S. government sensitive, or commercially sensitive information to unauthorized parties resulting in loss of confidentiality with a high impact as defined in FIPS PUB 199. Potential impact to personal safety: Lowat worst, minor injury not requiring medical treatment. Moderateat worst, moderate risk of minor injury or limited risk of injury requiring medical treatment. Higha risk of serious injury or death. Potential impact of civil or criminal violations is: Lowat worst, a risk of civil or criminal violations of a nature that would not ordinarily be subject to enforcement efforts. Moderateat worst, a risk of civil or criminal violations that may be subject to enforcement efforts. Higha risk of civil or criminal violations that are of special importance to enforcement programs. Determining Assurance Level: Compare the impact profile from the risk assessment to the impact profiles associated with each assurance level, as shown in Table 1 below. To determine the required assurance level, find the lowest level whose impact profile meets or exceeds the potential impact for every category analyzed in the risk assessment (as noted in step 2 below). Table 1 Maximum Potential Impacts for Each Assurance Level Assurance Level Impact Profiles Potential Impact Categories for Authentication Errors 1 2 3 4 Inconvenience, distress or damage to standing or reputation Low Mod Mod High Financial loss or agency liability Low Mod Mod High Harm to agency programs or public interests N/A Low Mod High Unauthorized release of sensitive information N/A Low Mod High Personal Safety N/A N/A Low Mod High Civil or criminal violations N/A Low Mod High        Page  PAGE 1 of  NUMPAGES 9  )+,.1<IWdef% (  # ] ^  ' eg˾ٰ՛|xqmqmqmqmqmh  h'ah h'ah'ah'a6] h'ahp k h'ah'a h'ah/h'<^ hNhtCJOJQJ^JaJhtCJOJQJ^JaJh7Aht\ ht\hNht5\ht hNhthvohtht>*CJaJhtht5>*CJ\aJ'+,2Jef% & J7$8$EƀлŦH$gdt 7$8$H$gdtgdtgdt & A R p ( ^ h & Fgd  & Fgd'<^ & Fgd'<^ & Fgd'<^gd'aW & F h7$8$EƀлŦH$^hgdtghs  lm"  u @FtuvhF9Eh:5hF9E6hhF9ECJaJhCJaJhF9ECJaJhF9E6CJ]aJh  h'ah'<^h'<^h'ahO h'ahO huh6nh6nhIhW huhu huhI h'ahIhF9Eh 51h m u3sTd=!!! & FL`Lgdie & F gdF9E & Fgd'a & Fgd & Fgd'a & Fgd'a & Fgd  & FgdI & Fgd6n & FgdI & FgdI13prsmuQTXbcdowkp~skh:5CJaJh:56CJ]aJ h'ah,h@N1h h'ahTAhI h'ah/h  h'ah h h'ah h'ah'<^h'<^hF9Eh 0J5OJQJ\h B*mH phsH &h 0J5B*OJQJmH phsH hhp khF9Eh:5*%}2 6 7 9 ! !3!*CJOJQJ^JaJ h8w5>*CJOJQJ^JaJ hIh8wh8whah8w5>* h8w5>*hahI h'ahIh'ahI0Jjh'ahIUj h'ahIU%77H8I8888979R9g9999999g:h:::%;&;'; & F 7$8$H$gd8w7$8$H$^`gd8wgd8wh7$8$H$^h`gd8w';~;;;;<<a<b<<<<<== =g>p>?$??? @7$8$H$^`gduM7$8$H$^`gduM h7$8$H$`hgduM 7$8$H$gduMgduMgd8w<<<<<<<=== =g>o>p>z>|>?#?&????? @"@QDYDZDĵyiyXGGG!huMhuMB*OJQJ^Jph!huMhuMB*OJQJ^JphhuMB*OJQJ\^Jph$huMhuMB*OJQJ\^Jph$huMhuM>*B*OJQJ^Jph*huMhuM>*B*OJQJ\]^JphhuMhuMB*OJQJphhuMhuMOJQJ^JhuMhuMOJQJ\^J huM\huMhuM\h8w5>*\huMhuM5>*\ @^@AOCPDQDZDEEGIKDMEMNMBNLNOOPRR%RCS h7$8$H$`hgduM 7$8$H$gduM7$8$H$^`gduM7$8$H$^`gduMZDfDEEEGEMMMNMZMBNKNNNR$R%R1RSSBSCSLSVVVνᲡzmeeYQGhaha5>*hICJaJhuMhuMOJQJ\huMOJQJhuMhuMOJQJ^JhuMhuMOJQJ\^JhuMOJQJ\^JhuMhuM>*OJQJ^J!huMhuM>*OJQJ\]^JhuMhuMOJQJ!huMhuMB*OJQJ^Jph$huMhuMB*OJQJ\^JphhuMhuMB*OJQJphhuMB*OJQJ\^JphCSMSS UVVV6W7WXY.YVYYYYZ/ZPZ[[h^hgdah^hgda ^`gdagdagdagduM7$8$H$^`gduM h7$8$H$`hgduMVVVV7WRW YY[[[[[!\9\u\x\z\~\\\b]g]M^W^[^`^d^_ _m_r__ `%`)`4a?aοtοοο_οοο_ο)haha56B*OJQJ\]ph haha56OJQJ\]haha5OJQJhahaOJQJ haha0JCJOJQJaJ#haha6B*OJQJ]phhahaB*OJQJph#haha5B*OJQJ\ph hahahaCJaJhaha5>* h8w5>*%[[[[$\x\\`]9^^^_k__#`a+cddefxggggda ^`gdagdah^hgda h^h`gda ^`gda?aaabb-c2cddddeeffggggggJhOhhhhh,i5iiiijqkrkkkkkl l l l變~l#haB*CJOJQJ^JaJph%hahaB*CJOJQJaJph+haha5B*CJOJQJ\aJphhaB*phhaCJaJ)haha56B*OJQJ\]ph#haha6B*OJQJ]ph#haha5B*OJQJ\phhahaB*OJQJph*gHhshh*iiiijqkrkkk $If gdagdagda h^h`gda ^`gda kk l llll $$Ifa$ckd $$Ifl2(##04 layt8w llllllllhlilllll*m+mVmWmmmmmmmmmmmmmmmmmmmmmmm´ypyeh E0JmHnHuhth0Jjhth0JUhthB*aJ phh5B*aJ ph hz[gh5B*CJ aJ phhjhUmHnHuhP:jhP:UhahaB*CJaJphhahaB*OJQJph#haha5B*OJQJ\ph'llSlXl]lblhlOI@@@@ $$Ifa$$Ifkd $$Ifl?r .(#` 04 layt8whlillllllOI@@@@ $$Ifa$$Ifkd $$IflRr .(#` 04 layt8wlllllllOI@@@@ $$Ifa$$Ifkd $$Ifl;r .(#` 04 layt8wllmmm$m*mOI@@@@ $$Ifa$$Ifkd$$Ifl;r .(#` 04 layt8w*m+m*B*phj#j TA Table Grid7:V0.)@1. TA Page NumberB'AB TAComment ReferenceCJaJ<R< TA Comment TextCJaJ@jQR@ TAComment Subject5\HrH TA Balloon TextCJOJQJ^JaJFVF RFollowedHyperlink >*B* phB^B 'a Normal (Web)dd[$\$6W@6 eStrong5OJQJ\o(<m@<'<^1 / 1.1 / 1.1.1 FVoV 6nDefault 7$8$H$!B*CJ_HaJmH phsH tH N&`N 6nFootnote ReferenceB*CJaJphFC@F aBody Text Indent B*ph<P@< a Body Text 2 B*phPK![Content_Types].xmlj0Eжr(΢Iw},-j4 wP-t#bΙ{UTU^hd}㨫)*1P' ^W0)T9<l#$yi};~@(Hu* Dנz/0ǰ $ X3aZ,D0j~3߶b~i>3\`?/[G\!-Rk.sԻ..a濭?PK!֧6 _rels/.relsj0 }Q%v/C/}(h"O = C?hv=Ʌ%[xp{۵_Pѣ<1H0ORBdJE4b$q_6LR7`0̞O,En7Lib/SeеPK!kytheme/theme/themeManager.xml M @}w7c(EbˮCAǠҟ7՛K Y, e.|,H,lxɴIsQ}#Ր ֵ+!,^$j=GW)E+& 8PK!Ptheme/theme/theme1.xmlYOo6w toc'vuر-MniP@I}úama[إ4:lЯGRX^6؊>$ !)O^rC$y@/yH*񄴽)޵߻UDb`}"qۋJחX^)I`nEp)liV[]1M<OP6r=zgbIguSebORD۫qu gZo~ٺlAplxpT0+[}`jzAV2Fi@qv֬5\|ʜ̭NleXdsjcs7f W+Ն7`g ȘJj|h(KD- dXiJ؇(x$( :;˹! I_TS 1?E??ZBΪmU/?~xY'y5g&΋/ɋ>GMGeD3Vq%'#q$8K)fw9:ĵ x}rxwr:\TZaG*y8IjbRc|XŻǿI u3KGnD1NIBs RuK>V.EL+M2#'fi ~V vl{u8zH *:(W☕ ~JTe\O*tHGHY}KNP*ݾ˦TѼ9/#A7qZ$*c?qUnwN%Oi4 =3ڗP 1Pm \\9Mؓ2aD];Yt\[x]}Wr|]g- eW )6-rCSj id DЇAΜIqbJ#x꺃 6k#ASh&ʌt(Q%p%m&]caSl=X\P1Mh9MVdDAaVB[݈fJíP|8 քAV^f Hn- "d>znNJ ة>b&2vKyϼD:,AGm\nziÙ.uχYC6OMf3or$5NHT[XF64T,ќM0E)`#5XY`פ;%1U٥m;R>QD DcpU'&LE/pm%]8firS4d 7y\`JnίI R3U~7+׸#m qBiDi*L69mY&iHE=(K&N!V.KeLDĕ{D vEꦚdeNƟe(MN9ߜR6&3(a/DUz<{ˊYȳV)9Z[4^n5!J?Q3eBoCM m<.vpIYfZY_p[=al-Y}Nc͙ŋ4vfavl'SA8|*u{-ߟ0%M07%<ҍPK! ѐ'theme/theme/_rels/themeManager.xml.relsM 0wooӺ&݈Э5 6?$Q ,.aic21h:qm@RN;d`o7gK(M&$R(.1r'JЊT8V"AȻHu}|$b{P8g/]QAsم(#L[PK-![Content_Types].xmlPK-!֧6 +_rels/.relsPK-!kytheme/theme/themeManager.xmlPK-!Ptheme/theme/theme1.xmlPK-! ѐ' theme/theme/_rels/themeManager.xml.relsPK] e  9<>Ag%x,~27<ZDV?a lmm7:<=?@BCFHJLOX& h!07'; @CS[gklhlll*mVmmmm89;>ADEGIKMNPQRSTUVW()@)_))) ***+ ,Q,,, -g----E.../a/eXXXXXXXX"$)46A!@  @Z B(    ;  @4 DraftTimes New RomanPowerPlusWaterMarkObject1c"$?  ;  @4 DraftTimes New RomanPowerPlusWaterMarkObject2c"$?  ;  @4 DraftTimes New RomanPowerPlusWaterMarkObject3c"$?0(  B S  ? 9A&t0" t&t _Hlt191118398 _Hlt191118399 _Hlt191118432 _Hlt191268481 _Hlt191268482!)!)+)e.e.e@@@@@")"),)f.f.e?l.?%?+?%?|+?D%?.?$? +?D,,?d:+?G!??!&9'9'"-"-=====]]^^e     &?'?'(-(-=====#]#]^^e 9 *urn:schemas-microsoft-com:office:smarttagsplace= *urn:schemas-microsoft-com:office:smarttags PlaceName=*urn:schemas-microsoft-com:office:smarttags PlaceType9*urn:schemas-microsoft-com:office:smarttagsStateB*urn:schemas-microsoft-com:office:smarttagscountry-region X,     FI"!*!''0044XX/Z0Z[[eeeeeeeeeeeeeeeeeee7777 8!8dGkGOOPPQ Q/]9]^^eeeeeeeeeeeeee3333333333z=?'''''')(*(,(,(f/444NNNNNeNeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee &%qf t>ON 4,5V:O:p e}F!2DB7Kcjv^WizV:OON 0KN:/DAR#/IQqYNasH6nIRTAee@eP@UnknownCommunity Network G* Times New Roman5Symbol3. * ArialA. Arial Narrow?= * Courier New7.  Verdana5. *aTahoma;WingdingsACambria Math"1h2f2f+f(dV 3(dV 3!884dYeYe 2QHX ?TA2!xxElectronic Signature Policy Administrator Diane McGill<         Oh+'0 ,8 X d p |Electronic Signature PolicyAdministrator Normal.dotmDiane McGill2Microsoft Office Word@G@~s@V@V (dV՜.+,D՜.+,H hp|  OSU3Ye Electronic Signature Policy Title(T\ _PID_HLINKS ContentTypeA0XWBhttp://www.ifap.ed.gov/dpcletters/attachments/gen0106Arevised.pdfHV:http://oregonstate.edu/dept/budgets/genupol/gupaccep2.htm"x(http://www.leg.state.or.us/ors/084.html[ Ehttp://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdfP Ehttp://www.ed.gov/legislation/FedRegister/finrule/2004-2/042104a.pdfIghttp://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=106_cong_public_laws&docid=f:publ229.106.pdf,.+http://www.cio.gov/eauthentication/era.htmu.8http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf Document  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXY[\]^_`abcefghijklmnopqrstuvwxyz{|}~Root Entry F`AbData Z1TabledgWWordDocument4SummaryInformation(DocumentSummaryInformation8CompObjy  F'Microsoft Office Word 97-2003 Document MSWordDocWord.Document.89q