Arizona Secretary of State - Ken Bennett


 
Arizona Secretary of State Logo AZ.gov Arizona's Official Web Site

Overview
POLICY AUTHORITY PROCEDURES

For the Arizona Electronic Signature Infrastructure (AESI)
Version 1.00
September 1999


download Word version

TABLE OF CONTENTS

1 Organization And Governance

1.1 AESI Functions, Roles and Parties
1.2 The Role of a Policy Authority

1.2.1 Policy and Business: The Parties and The Transactions
1.2.2 Who are the Stakeholders?
1.2.3 What Underlying Transactions are to be Facilitated by AESI?
1.2.4 Certificate Policy Subject to Primary Business Drivers
1.2.5 Promulgation of Policy as a Function of Governance

1.3 The Structure of Governance
1.4 Form of the Policy Authority

2 Building a Business and Legal Model

2.1 Basic Conceptual Building Blocks

2.1.1 Functions Allocated to Roles
2.1.2 From Roles to Obligations and Parties

2.1.2.1 Contracts and Accounts

2.1.2.1.1 Contract Formation
2.1.2.1.2 System Uniformity and Closure

2.1.2.2 Certificates and the Problem of Certificate Meaning

2.1.3 From Obligations to Liability and Legal Remedies

2.1.3.1 Choosing a Forum
2.1.3.2 Remedies
2.1.3.3 Enforcing Remedies and Financial Responsibility

2.1.4 Conclusion on Model Building Blocks

2.2 Elements Required in a Certificate Policy

2.2.1 Issuer Functions and Obligations

2.2.1.1 Issuer-Subscriber Functions and Obligations
2.2.1.2 Issuer-Relying Party Functions and Obligations
2.2.1.3 Other Issuer-Related Roles

2.2.1.3.1 Registrar
2.2.1.3.2 Certificate Manufacturer
2.2.1.3.3 Other Roles Assisting Issuers

2.2.2 Subscriber Functions and Obligations
2.2.3 Relying Party Functions and Obligations
2.2.4 Repository Functions and Obligations

2.2.4.1 Repository-Subscriber Functions and Obligations

2.2.4.1.1 Privacy and Other Information Rights
2.2.4.1.2 Other Functions and Obligations

2.2.4.2 Repository-RelyingParty Functions and Obligations
2.2.4.3 Repository-Issuer Functions and Obligations

2.2.4.3.1 Publication Functions and Obligations
2.2.4.3.2 Other Functions and Obligations


1. Organization And Governance

A Certificate Policy is used to define the interrelated rights and obligations of stakeholders using electronic signatures to "sign" electronic documents. This signing serves the same purposes as physically signing a document. These procedures deal only with electronic signatures and associated certificates used to authenticate the identity of an individual. These procedures are intended for use within a relatively closed environment, the Arizona Electronic Signature Infrastructure (AESI). Specifically, these procedures are designed for the use of electronic signatures with and by state of Arizona government agencies in such environments where the two parties have a predefined bounded relationship.

1.1 AESI Functions, Roles and Parties

There are sets of functions that can be logically and conveniently grouped and delegated. Most of these functions can be divided into several sets of functions with each set representing a role. Roles can be named according to the nature of the functions in each set. It is important to be clear that a particular party may perform one or more roles in the AESI. And evolving business models may change the way in which functions are logically grouped. Which may make it necessary to further evolve the naming of roles in the future.

The following roles have been identified core ESI roles:

ESI Service Providers

  • Policy Authority
  • Issuer (Certification Authority)
  • Certificate Manufacturer
  • Registrar (Registration Authority)
  • Repository

End Entities

  • Subscriber
  • Relying Party

A description of how functions are assigned to roles is developed in the Building a Business and Legal Model Section.

1.2 The Role of a Policy Authority

The Policy Authority is the party with final authority and responsibility for specifying a Certificate Policy. Setting a Certificate Policy is a function of the PA establishing the manner in which a particular ESI structure establishes the roles, rights and responsibilities of people who participate within ESI.

1.2.1 Policy and Business: The Parties and The Transactions

The Policy Authority is responsible for assuring that the activities of AESI Service Providers and End Entities are conducted in a sound and efficient manner. The Policy Authority drafts one or more Certificate Policies to fit the basic business needs of the parties, with various Certificate Policies differing depending upon the nature of the participants involved and what transactions they seek to conduct.

1.2.2 Who are the Stakeholders?

In addition to the Policy Authority, the AESI stakeholders are End Entities and Service Providers. The purpose of the AESI is to enable various economic and legal transactions between End Entities (where one End Entity represents the State of Arizona or one of its business units). Stakeholders can come from any number of groups, such as citizens, business organizations, other government entities, employees or any number of other groups engaged in transactions with the government of Arizona.

1.2.3 What Underlying Transactions are to be Facilitated by AESI?

Transactions that might be facilitated by using AESI include nearly any current transaction that occurs over-the-counter, by phone or mail. Note, however, that the same parties who engage in different transactions may require different policies for each transaction due to the variations in the underlying legal and economic systems related to each transaction. It might be convenient for the same parties to use the same certificates under the same Certificate Policy as part of every transaction but it may not be prudent to do so. The regulatory requirements governing payment systems, for instance, are so different from the regulatory requirements governing submission of a bid for a public works project that the obligations and rights of the parties may well require different certificate policies.

1.2.4 Certificate Policy Subject to Primary Business Drivers

The form of an electronic transaction is a means to an end. The form should follow the function of the organization and the business process being conducted. The Policy Authority shall endeavor to develop Certificate Policies that meet a wide range of business needs, but each organization will need to ascertain which CP meets the particular needs of a particular process. And the parties will often need to draft a contract to incorporate additional rights and obligations specific to that process.

1.2.5 Promulgation of Policy as a Function of Governance

A Certificate Policy may include sections detailing the manner in which the Certificate Policy may be amended. As a general rule, however, any material change to the Certificate Policy will lead to it being superceded by another CP. The old CP will remain in effect for any existing contracted use (unless the contract specifies otherwise). New contracts contemplating AESI may not use a superseded or otherwise obsolete Certificate Policy.

It is not the mission of the Policy Authority to use and promote AESI. The use of AESI is for the purpose of securing and authenticating communications and data interchange that is of relatively high value, sensitive, or otherwise important to the mission of Agencies and other business units of the State of Arizona.

1.3 The Structure of Governance

The Policy Authority has ultimate responsibility for specifying the Certificate Policies that enable Arizona’s Electronic Signature Infrastructure. The Policy Authority is the governing body responsible for drafting and promulgating the Certificate Policies in a manner that supports and reflects the needs of the underlying relationships and transactions.

There will be opportunities for agency and public comment. These opportunities will include presentation of draft Certificate Policies to the State’s CIO Council, ITAC, any appropriate Government Information Technology Agency (GITA) or Secretary of State based task-group or committee. The PA will maintain a collaborative draft and review process with the Office of the Secretary of State, GITA and the State Treasurer’s Office consistent with the statutory responsibilities for electronic signature use and management that each has.

Some implementations (e.g. electronic commerce) may require a web of relationships that spans traditional organizational boundaries and jurisdictions. This may require cooperation within newly evolved organizational structures and that may require adjustments to the public comment process.

Several aspects of AESI are controlled by statute, administrative rule and Statewide IT standards. Each Certificate Policy will be bound by those requirements and will not circumvent them.

Fundamental policy matters such as determination of the scope of community and applicability; obligations and liability of the parties; fees and financial responsibility; and the confirmation and identification of certificate applicants require decisions by a those with responsibility to steer AESI. A Certificate Policy is designed to manage high value, sensitive or mission critical relationships and transactions.

Any use of electronic signatures with or by Arizona Agencies is assumed to be for purposes defined within Arizona’s Electronic Signature Statute unless this purpose is expressly denied and said denial is agreed to by all parties to its use.

1.4 Form of the Policy Authority

The Office of the Secretary of State serves as the Policy Authority. The Secretary of State shall designate the person or persons with delegated responsibility to act for and as the Policy Authority.

2. Building a Business and Legal Model

The whole area of electronic and digital signature use is rapidly evolving. There are no best practices, only best current practices. The Policy Authority is charged to assure, through constant due diligence, that these Practices and the Certificate Policies evolve in a rapid yet prudent fashion to meet the needs of the State of Arizona and it’s agencies and their business partners. All such practices shall be with the best interests of the citizenry of Arizona paramount.

2.1 Basic Conceptual Building Blocks

The Policy Authority’s evolving organizational model-building follows these key steps:

  • Derive functions from the operational requirements of the appropriate electronic signature technology. Certain actions must be done by devices and the people or business entities that run those devices for that technology to work. A list of functions or things that must be done for the technology to work effectively comprises the starting point for a business-legal framework for an electronic signature business application. Deriving functions from roles revolves about how usefully the technology performs the application.
  • Allocate functions to roles. The functions that must be performed for electronic signature technology to work are assigned in the Certificate Policy to the classes of participants involved (parties). These classes or roles are named and their functions and qualifications described. This labeling and describing leads to defining role-terms such as "Subscriber" or "Approved CA."
  • Commit parties to the roles through binding obligations. Each party interested in participating in an application become actual participants by committing to contracts or otherwise becoming subject to the legally binding requirements that involve enforceable duties. These legally binding commitments are obligations that can be enforced judicially in case of a failure to perform according to the commitment. Parties are the persons who are thus committed.
  • Resolve disputes if an obligation is breached. There is a liability if a judicial or agreed alternative administrative tribunal has determined an unsatisfied obligation exists. The Certificate Policy shall define minimum obligations and judicial recourse. Each party will be responsible for assuring that any additional commitment needed is set down in contracts or otherwise becomes subject to legally binding requirements external to the Certificate Policy.

2.1.1 Functions Allocated to Roles

    Functions are tasks performed by devices and people so that the electronic signature infrastructure works effectively. These tasks derive from the limitations of the particular technology employed and the events and conditions that must occur to make that technology useful.

    The functions must combine to provide the specific conditions that Arizona’s Electronic Signature Statute requires for a valid signature. These functions will be assigned to roles in the most effective manner available.

2.1.2 From Roles to Obligations and Parties

    Obligations are legally binding duties, and the persons that they bind are termed "parties" in these Procedures. Certificate Policies usually will not name their participants, and they will rarely commit parties to perform their roles with binding legal force. In the absence of contracts between the parties, the courts will extend generally applicable legal principles to cover issues arising in electronic signature applications.

    [per CARAT Guidelines - By itself, a Certificate Policy is generally not legally binding, unless it is imposed by sovereign power such as through statutory enactment or regulatory adoption. Without sovereign imposition, the parties can bind themselves to obligations by agreeing contractually to be subject to the Certificate Policy. In the absence of contracts or sovereign enactments, the courts will extend generally applicable legal principles, called the "common law" in the Anglo-American tradition, to cover issues arising in public-key applications.]

2.1.2.1 Contracts and Accounts

    A contract that gives binding legal effect to a Certificate Policy is termed an "implementing contract."

2.1.2.1.1 Contract Formation

    In general, a contract generally requires: parties - entities who have the legal capacity to contract; mutual assent - the parties come to a "meeting of the minds" on the essential terms of the contract; consideration - the contract provides mutual benefit.

    Contract parties can indicate mutual assent and form contracts in the following ways, among others, depending on the needs of a particular application:

  • One-stop double enrollment: As an example, when a person agrees with an Issuer to be a Subscriber, the person can also agree to be a Relying Party.
  • Online, digitally signed contract: If a person, especially a prospective Relying Party, approaches a contract-based system online and has an electronic signature capability then the person can use that electronic signature to accept and sign an online contract offer.
  • Clickwrap: Sometimes contracts can be formed by clicking an on-screen button labeled "I agree" or by a similar form of electronic assent. The document proffering the contract and its agreement button should record evidence for subsequently proving that the contract-formation event occurred. This evidence should include the system date when the click occured, the user’s login identification, and sufficient other user information to assure reasonable confirmation that the event occurred by this person’s action.

2.1.2.1.2 System Uniformity and Closure

    Note that contracts must be made one by one. They can have more than two parties, but all of the parties must complete the assent process for the contract to be validly formed.

    The one-by-one nature of contracting makes it difficult to be certain that all participants in an application are bound by its rules, including its Certificate Policy. Achieving this assurance is particularly difficult in the case of Relying Parties. Any application relying on a Certificate Policy will need to preclude prospective Relying Parties from relying on certificates if they cannot demonstrate they have contracted for participation in the system. Such inclusion or preclusion is the responsibility of the application’s participating parties.

    Application parties might review the CARAT Guidelines for more detail the how and why of Relying Party issues and methods of dealing with those issues.

    An application’s implementing contracts should incorporate the Certificate Policy and be consistent with it. But, where reasonable, such implementing contracts may include additional provisions consistent with this Practice and the Certificate Policy to further govern of the relationship between the parties. The Policy Authority recognizes that the relationship between a Service Provider and the End User is the framework within which electronic signature services are obtained and provided, and those relationships must have enough range and flexibility to achieve mutual benefit.

2.1.2.2 Certificates and the Problem of Certificate Meaning

Certificates generally have a standardized form consisting of limited range of fields. This range of fields can be used in ways that give the value in a field different meaning depending on the context it is used in. This limited but ambiguous set of values means it is not possible to know from the face of a certificate exactly what it means. Standardized certificates can leave the rights and obligations of the parties, particularly of the Issuer and Relying Party, in substantial uncertainty. This is solved by using a certificate profile that defines: 1) a specification of the fields, 2) their permissible content, and 3) the range of permissible interpretation for those fields for a particular certificate type. This certificate profile should be defined in a documentary fashion that clarifies the meaning of the certificate’s fields.

A Certificate Policy may define some essential fields for that CP. An application’s implementing contract must take into account the certificates to be issued and the interpretation to be given them. An implementing contract may define fields as well, but it may not alter the use of any field defined in the CP. A common way for the implementing contract to deal with the certificates to be issued is for the contract to provide for acceptance of those certificates (by the Subscriber) or for reliance on those certificates (by the Relying Party) in their documentary forms only. The contract is then somewhat open-ended and allows certificates to vary by type, application, and other certificate-specific circumstances, while the certificates all fall under the terms and conditions of the implementing contract and Certificate Policy.

Consideration should be given to the probable need to cross-certify where the fields in the "other" certificates may be defined differently. Even if cross-certification seems extremely unlikely, means of implementing cross-certification should be considered even as the implementing contract is being created. Plans and processes are known to change.

2.1.3 From Obligations to Liability and Legal Remedies

For clarity, the term "obligation" is used to identify a promise while a "liability" is used to identify promise that is not only broken has had the remedies adjudicated as due and immediately enforceable.

Converting an obligation into a liability requires a forum to conduct adjudication or a similar dispute-resolution process culminating in a judgment, order, or other award.

2.1.3.1 Choosing a Forum

    Each Certificate Policy shall establish the laws of the State of Arizona as the primary jurisdiction for any claim. There may be additional conditions regarding arbitration or other non-judicial processes to effect adjudication. Implementation contracts may expand or extend the processes defined in the CP.

2.1.3.2 Remedies

    A Certificate Policy may stipulate minimum conditions and requirements that each party must meet to be accepted as a party to the ESI formed by the CP. Minimum conditions and requirements may include requiring performance bonds or Errors and Omissions insurance.

    Whether defining a Certificate Policy or drafting an implementation contract, it is important, in considering the risk of nonperformance, to consider not only whether an appropriate forum will conclude that liability exists for the nonperformance of an obligation but also what remedy that forum is likely to award. The CP and any implementation contract needs to take into account the consequence of nonperformance where the timeliness of the remedy may be as important as the form of award.

2.1.3.3 Enforcing Remedies and Financial Responsibility

    While the breach of an obligation can be reduced to a liability for which a forum awards a remedy, that remedy will mean little if it cannot be realized.

    The ability of a Service Provider to actually make good its promises through real assets or appropriate insurance is an important factor to consider in evaluating its trustworthiness and the significance of its promises.

2.1.4 Conclusion on Model Building Blocks

    The Policy Authority has articulated the four-cornered model as the guiding organizational model. This should be recognized as a basic framework on which the evolving business needs and technology will inevitably lead to Certificate Policies and the Electronic Signature Infrastructures formed by them creating more complex models.

2.2 Elements Required in a Certificate Policy

2.2.1 Issuer Functions and Obligations

The Issuer of a certificate (generally known as a Certification Authority or CA) has certain functions and obligations relating to Subscribers and Relying Parties.

2.2.1.1 Issuer-Subscriber Functions and Obligations

The Certificate Policy shall establish explicit functions, obligations and remedies between Issuer and Subscriber.

2.2.1.2 Issuer-Relying Party Functions and Obligations

The Certificate Policy shall establish explicit functions, obligations and remedies between Issuer and Relying Party.

2.2.1.3 Other Issuer-Related Roles

An Issuer’s basic set of obligations can be divided up and reallocated by a Certificate Policy or delegated by subcontract in many ways. By definition, an Issuer is the person listed in the certificate in the issuer field.

Some of the functions associated with the Issuer are often performed by other roles (e.g. some functions that the Issuer often performs can be assigned to the roles of Registrar or Certificate Manufacturer). The Certificate Policy shall establish what delegation is allowed and explicit functions, obligations and remedies between Issuer and any Party performing those functions.

2.2.1.3.1 Registrar

    Sometimes it is useful and prudent to have a Registrar local to the Subscribers rather than having the Issuer develop its own extensive local presence. For example, an agency obtaining certificates for its employees is usually in a good position to address the certification needs of its employees, the prospective Subscribers, and to provide high-quality certificate information

    The Certificate Policy shall establish whether a local Registrar is allowed and the extent of any delegated of functions, obligations and remedies between Issuer and Registrar.

2.2.1.3.2 Certificate Manufacturer

    A Certificate Manufacturer provides operational services for an Issuer. The exact obligations and functions of a Certificate Manufacturer depend on the contractual arrangements between Issuer and manufacturer.

    The Certificate Policy shall establish whether a Certificate Manufacturer is allowed and the extent of any delegated of functions, obligations and remedies between Issuer and the Certificate Manufacturer.

2.2.1.3.3 Other Roles Assisting Issuers

    The Certificate Policy shall establish whether the Issuer may subcontract other roles and the extent of any delegated of functions, obligations and remedies between Issuer and the other roles.

2.2.2 Subscriber Functions and Obligations

    The Subscriber owes duties mainly to the Issuer and to Relying Parties. The Certificate Policy shall establish the Subscriber’s functions, obligations toward other parties and any remedies available against Subscriber.

2.2.3 Relying Party Functions and Obligations

Relying Parties owe duties mainly to the Issuer and to Subscribers. The Certificate Policy shall establish the Relying Party’s functions, obligations toward other parties and any remedies available against Relying Party.

2.2.4 Repository Functions and Obligations

2.2.4 Repository Functions and Obligations

2.2.4.1 Repository-Subscriber Functions and Obligations

2.2.4.1.1 Privacy and Other Information Rights

    Subscribers are the persons about whom information is published in a Repository that is generally available as an online information resource. The Repository may have an obligation to safeguard the Subscriber’s rights of privacy, confidentiality, and information accuracy, if implementing contracts, the Certificate Policy, or any applicable statutes or regulations provide for such rights.

    The Certificate Policy shall recognize the right to any lawful access to Subscriber information.

2.2.4.1.2 Other Functions and Obligations

    The Certificate Policy shall establish explicit functions, obligations and remedies between Repository and Subscriber.

2.2.4.2 Repository-RelyingParty Functions and Obligations

    The Certificate Policy shall establish explicit functions, obligations and remedies between Repository and Relying Party.

2.2.4.3 Repository-Issuer Functions and Obligations

2.2.4.3.1 Publication Functions and Obligations

The Certificate Policy shall establish minimum publication functions, obligations and remedies between Repository and Issuer.

The Repository and the Issuer will agree on the terms and conditions governing publication by the Issuer of information (such as certificates and notices of revocation) into the Repository. As a minimum, this agreement shall meet the requirements established in the CP. A Repository is obligated to perform according to that agreement.

2.2.4.3.2 Other Functions and Obligations

The Certificate Policy may establish other explicit functions, obligations and remedies between Repository and Issuer.