+

WO2000048360A1 - Procede et systeme de prestation de services, notamment de services orientes certification - Google Patents

Procede et systeme de prestation de services, notamment de services orientes certification Download PDF

Info

Publication number
WO2000048360A1
WO2000048360A1 PCT/US2000/003550 US0003550W WO0048360A1 WO 2000048360 A1 WO2000048360 A1 WO 2000048360A1 US 0003550 W US0003550 W US 0003550W WO 0048360 A1 WO0048360 A1 WO 0048360A1
Authority
WO
WIPO (PCT)
Prior art keywords
participant
relying
warranty
customer
issuing
Prior art date
Application number
PCT/US2000/003550
Other languages
English (en)
Other versions
WO2000048360A9 (fr
Inventor
Mack Hicks
Regina Seiler
Guy S. Tallent, Jr.
Kristin Kupres
Allen Freudenstein
Original Assignee
Mack Hicks
Regina Seiler
Tallent Guy S Jr
Kristin Kupres
Allen Freudenstein
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mack Hicks, Regina Seiler, Tallent Guy S Jr, Kristin Kupres, Allen Freudenstein filed Critical Mack Hicks
Priority to AU28787/00A priority Critical patent/AU2878700A/en
Publication of WO2000048360A1 publication Critical patent/WO2000048360A1/fr
Publication of WO2000048360A9 publication Critical patent/WO2000048360A9/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management

Definitions

  • the data security market (including hardware) is anticipated to expand to $13.1 billion in sales by the year 2000, up from $6.9 billion in 1997.
  • the Gartner Group estimates that the market for digital certificates totaled about $100 million in 1998 and will continue to show 100 percent growth in the near term. Soundview Financial recently predicted the certificate market will hit $1 billion in 2001.
  • member institutions create an entity, referred to hereafter as the root entity, to establish a global, interoperable network of financial institutions which operate as certification authorities.
  • each participating financial institution (each, a "participant") issues digital certificates to customers and corporations and their employees, based on a set of uniform system rules and business practices.
  • the root entity provides the infrastructure within which the system participants provide these services, including establishing technological and procedural systems to support system activities, developing and maintaining rules and regulations governing participation in the system, providing ongoing monitoring and data processing functions to limit the risks to system members and their customers, and establishing a dispute resolution mechanism for issues arising out of use of the system.
  • the technological, procedural, and legal frameworks established by the root entity and its members permit those members to provide more meaningful and better controlled identity certification services than have previously been available. By doing so, the system encourages the adoption of trusted business-to-business electronic commerce.
  • the root entity is intended to be a commercially viable, for-profit business that facilitates domestic and international business-to-business electronic commerce by creating a framework for the provision of certification authority services by its participants. Participants use the system to manage the risks involved in acting as certification authorities issuing digital certificates to parties who can then use those certificates to affix digital signatures to messages sent through electronic communications systems, including the Internet.
  • the system is a "closed" system, in which only parties that have agreed to abide by the system's rules and regulations are allowed to participate.
  • the system and its members operate in accordance with a set of operating rules (the "operating rules").
  • the system is comprised of regulated financial institutions coming together to take the basic technology provided by public key cryptography and public key infrastructure (PKI), and combine it with adherence to a common set of operating rules to facilitate electronic commerce. While the system provides the infrastructure for participating organizations, the service leverages the participants' existing customer base, and the financial institution entity as a trusted financial intermediary.
  • the system is a multi-vendor system, and allows participants to customize the management of identity risk when dealing with individuals over an electronic medium with applications that best meet each particular participant's customer needs.
  • LI participants may join the system either directly, as “Level One Participants” (LI participants), or indirectly, as “Level Two Participants” (L2 participants).
  • LI participants may issue certificates either directly to subscribing customers or to L2 participants.
  • L2 participants may issue certificates only directly to subscribing customers. In other respects, the two types of participants operate within the system in the same manner.
  • the system may be used to facilitate business-to-business e-commerce.
  • the service provided by the system fits well with the needs of mid-size to large institutions for both secure transactions and communications with other businesses.
  • the disclosed system comprises the following key elements:
  • the system provides an infrastructure for managing risk.
  • the following six, root entity-level key risk areas are analyzed and appropriate controls established within each: a. Operational b. Reputation c. Regulatory d. Strategic e. Credit f. Liquidity/Financial
  • a "closed" system is utilized - meaning that both sides of any transaction, are contractually bound to the same set of system rules and operating procedures. From a participant standpoint, the ability to track and monitor outstanding warranties is another feature which also provides the ability to manage risk. 2.
  • the root entity's responsibilities include delivery of the following: a. root technology. b. signing keys of all participating financial institutions, which in turn issue certificates to end-users or sign the keys of issuing corporations. c. establish the infrastructure to facilitate emergence of e-commerce applications, not the applications themselves.
  • the system provides a platform for various technologies to "interoperate" with each other.
  • New vendors approach "interoperability" from both a sponsoring and a participating institution standpoint.
  • Technical interoperability is structured in this way to ensure that compliance with technology specifications is equivalent to achieving actual operational interoperability.
  • System interoperability extends beyond technology, to the operating rules, system procedures, and issuance practices of all participants within the system hierarchy.
  • Warranty certificates are used to interact with multiple trading partners, across multiple business applications, in multiple jurisdictions.
  • the trust feature, and benefit from it, is addressed by the system in a number of ways: a.
  • the system leverages the traditional bank role in identifying customers for purposes of facilitating commerce, and operating as service providers in a regulated environment subject to significant oversight and regulation.
  • b. The network is dedicated to maintaining high minimum standards.
  • c. A digital certificate is only as trustworthy as the certifying authority that issued it. The accuracy and validity of a digital certificate is key to a recipient's reliance on a digital signature. By issuing such a digital certificate, the certifying authority certifies the identity of the person sending a message signed with the certificate.
  • d. Through establishment and compliance with system rules, a PKI is developed that ensures the integrity of the certifying authority's operations.
  • the system requires a party to obtain affirmative confirmation of the validity of an identity.
  • the system also provides the means to obtain that confirmation and a warranty thereon on a real-time or near real-time basis through an on-line status check.
  • CTLs certificate revocation lists
  • the system primarily relies on checks of certificates with known "good status" rather than the more customary check of certificates that are known to be bad.
  • Warranty/Assurance aggregate limits on exposure to identity warranties
  • the system design imposes aggregate limits on the exposure that any issuing participant may incur through explicit warranties granted with respect to identity certificates issued by that institution. Because each warranty is bounded by the agreements among the parties, both in terms of financial risk and duration, it is possible for each LI participant and the root entity to monitor the participant's compliance with this limit on a real-time basis.
  • the root entity monitors the cap of all issuing participants on a daily basis. In addition, the system monitors the cap on a real time basis.
  • the transactions may be captured on a real-time basis, and reported on a periodic basis (to be determined) to the root entity.
  • the root entity can impose sanctions on participants for violation of warranty cap rules.
  • the system comprises a mechanism by which to increase or decrease warranty cap. c. Required collateral posting
  • collateral is required of all institutions issuing this assurance.
  • the collateral is based on a combination of two criteria:
  • An individual participant is required to post a specific amount of collateral in accordance with each participant's specific credit rating. Credit rating is checked on a periodic basis, or whenever revised by a rating firm. (It may take the form of a continuous monitoring of credit rating, leading to changes in collateral happening in concert with changing credit ratings).
  • the ability to provide for shuffled and fragmented root keys is another security feature specific to the system.
  • Fig. 1 is a high level graphic depiction of the system structure
  • Fig. 2 is a block diagram illustrating the relationship between the parties in the system operating model
  • Figs. 3-7 are a series of conceptual diagrams that illustrate the flow of data through the system for initialization, validation, and warranty processes
  • Fig. 8 illustrates aspects of the dispute resolution process of the present system
  • Fig. 9 illustrates aspects of the collateral management system of the present system
  • Figs. 10-12 illustrate aspects of user interaction with the present system
  • Fig. 13 illustrates aspects of the root entity of the present system
  • Fig. 14 illustrates aspects of a participant of the present system.
  • Fig. 1 is a high level graphic depiction of the system structure.
  • the system comprises a root entity 102 that is initially formed as a global joint venture of eight founding member banks 104, and a technology partner 104 2 .
  • Equity membership is then expanded among regulated financial institutions to achieve a diversity of ownership from all major regions of the globe as well as from other financial industry sectors.
  • the system further comprises a plurality of LI participants 106,, a plurality of corporate clients 108, and a plurality of employees 110 of corporate clients 108. Also part of the system, although not shown in Fig. 1, are a plurality of L2 participants 106 2 . L2 participants 106 2 also typically have a plurality of corporate clients 108 which each typically have a plurality of employees 110.
  • root entity 102 creates an infrastructure within which participants 106 provide system services. Specifically, root entity 102 engages in the following functions:
  • Root entity 102 is a for-profit entity, significant revenue opportunities also exist at the individual participant level. By offering add-on electronic services, or by "electronifying" existing customer services, participants 106 compete with each other to attract incremental revenue. Participants 106 also have the right to independently determine products, bundles, and services offered, and fees charged to customers. Root entity 102 does not address the fees that participants 106 charge their customers, other than establishing a processing fee for each validation to be paid by one participant to another; there is no interchange fee. This structure enhances the market for participant developed electronic commerce applications, and provides for the transformation of traditional bank products for electronic use. All LI participants 106, are required to act as an issuing participant.
  • Participants 106 providing the services described above engage in the following activities:
  • L2 participants 106 2 are also required to be financial institutions. Specific eligibility requirements should be included within the operating rules.
  • the role of an L2 participant! 06 2 is to issue certificates to its customers 108 and act as principal on warranties issued. LI participants 106,, provide the outsourced reliance manager function to their L2 participants 106 2 .
  • the criteria for participation are dependent upon the entity's role as an LI participant 106, L2 participant 106 2 , corporation (customer 108), or user (employee 110). In all cases, however, the criteria are designed to:
  • Participants 106 may be terminated only for specific reasons related to preserving system integrity and favorable risk posture. Procedures provide participants 106 with notice and opportunity to cure deficiencies. However, participants 106 may be suspended on an immediate and a summary basis to preserve system integrity. L2 Participants 106 2 may be suspended or terminated either by an LI participant 106, at request of root entity 102, or by root entity 102 directly (as backstop). Participants 106 may also elect to suspend or terminate membership in the system. Terminated participants 106 are required to take all necessary steps to terminate system-supported services, and to immediately inform their customers 108. Root entity 102 must also be able to invalidate (almost immediately) the subsequent validation of any certificates issued by suspended or terminated participants 106. (The above provisions apply equally to suspended participants 106.) II. Operational Concepts
  • the system is based on an operating model with five primary parties: root entity 102, an issuing participant 10, a subscribing customer 20, a relying participant 30, and a relying customer 40.
  • root entity 102 The relationship between these parties is illustrated in Fig. 2.
  • Fig. 2 Also shown in Fig. 2 is a collateral custodian 112.
  • Each component depicted in Fig. 2 is certified by root entity 102 and possesses its own certificate, which in turn is validated through a trusted hierarchy. Certificates are issued to LI participants 106,, which then issue their certificates to L2 participants 106 2 or customers 108.
  • the relationships, as depicted in Fig. 2, are: subscribing customer 20 is a customer of issuing participant 10, and relying customer 40 is a customer of relying participant 30.
  • each customer 108 interacts with the system through its respective participant 106.
  • a seller asks its financial institution (LI participant) to validate the credentials of a buyer.
  • the seller's financial institution contacts the buyer's financial institution, which in turn attests to the identity of its customer, a buyer.
  • the process takes place the same way, with each party relying on a digital certificate and digital signature by first consulting its own financial institution.
  • the financial institution may offer an identity warranty service for either party, as described in more detail below.
  • issuing participant 10 is the primary obligor on warranties, while relying participant 30 acts as an agent.
  • Each LI participant 106 maintains a collateral account with a collateral custodian which is distinct and separate from issuing participant 10, and which will support the warranty issuance capability.
  • Figs. 3-7 are a series of conceptual diagrams that illustrate the flow of data through the system for initialization, validation, and warranty processes.
  • Fig. 3 is described in this section.
  • Figs. 4-7 are described below.
  • each entity in the operating model of Fig. 2 comprises elements that facilitate the business processes described below.
  • root entity 102 comprises a certificate authority 302 and a participant repository 304.
  • Certificate authority 302 issues digital certificates to LI participants 106, as described in more detail below.
  • Issuing participant 10 comprises a certificate authority 306 that is connected to a repository 308. Certificate authority 306 issues digital certificates to customers of issuing participant 10, as described in more detail below. Repository 308 is further connected to an
  • IP certificate risk check and reporting module 310 further comprises bank legacy systems 312, other transaction systems 314, and other tracking DBFs 316.
  • Elements 308-316 are all connected to an intelligent messaging gateway (IMG) router 318 through which flows all messages to and from issuing participant 10 relating to the provision of system services.
  • IMG intelligent messaging gateway
  • Subscribing customer 20 has a digital certificate 322 that it receives from issuing participant 10.
  • Subscribing customer 20 also has the necessary equipment to communicate with relying customer 40.
  • Relying participant 30 comprises a certificate authority 324 that is connected to a repository 326. Certificate authority 324 issues digital certificates to customers of relying participant 30, as described in more detail below. Repository 326 is further connected to an IP certificate risk meter and reporting module 328. Relying participant 30 further comprises bank legacy systems 330, other transaction systems 332, and other tracking DBFs 334. Elements 326-334 are all connected to an IMG router 336 through which flows all messages to and from relying participant 30 relating to the provision of system services.
  • Relying customer 40 has a digital certificate 338 and a client IMG formatter 340. Messages from relying customer 40 requesting a system service are formatted by IMG formatter 340 and transmitted to IMG router 336.
  • C. Proposed Business Process The operating model is useful in understanding the structure of the system. To better understand the system at work, closer examination of the processes on the front and back-end is required. There are a number of discrete steps that occur within the normal operation of the system.
  • step A a prospective LI participant 106, applies for admission to the system.
  • step B the applicant receives and signs a participation agreement and agrees to be bound by the operating rules.
  • the prospective LI participant must agree to act as an issuing participant 10 in order to also act as a relying participant 30.
  • step B root entity 102 sets a maximum warranty cap for the applicant and a collateral amount that the applicant is required to post.
  • the specific amount of collateral that a participant must post per warranty certificate issued varies from participant to participant based on established criteria - and as discussed below.
  • Root entity 102 also orients the LI participant 106, and helps establish an implementation schedule.
  • the new LI participant 106 establishes internal certificate authority operation with appropriate testing and sign-off by root entity 102.
  • the new LI participant 106 also opens a collateral account with collateral custodian 112 and deposits funds as required by root entity 102.
  • Collateral custodian 112 notifies root entity 102 when such funds are transferred by the new LI participant 106, to collateral custodian 112.
  • Collateral custodian 112 provides monthly reports to root entity 102 for each collateral account established at collateral custodian 112.
  • the LI participant 106 requests a digital certificate from root entity 102.
  • root entity 102 issues the requested digital certificate to the LI participant 106,.
  • issuing participant 10 and relying participant 30 execute and exchange an inter LI contract.
  • the warranty certificate is needed to obtain the validation and warranty assurance services discussed below.
  • Warranty certificate issuance is described in connection with Fig.
  • step 502 subscribing customer 20 requests a certificate from issuing participant 10.
  • step 504 issuing participant 10 does an appropriate due diligence to ensure that "know your customer" requirements have been met.
  • a request for a certificate must be authenticated and approved before certificate issuance.
  • step 506 subscribing customer 20 receives and signs a customer agreement with issuing participant 10
  • step 508 the issuing participant 10 issues the certificate to subscribing customer 20 (see also step G in Fig. 4). Analogous steps are performed to issue a digital certificate to relying customer 40.
  • step A subscribing customer 20 initiates a transaction with relying customer 40.
  • step B relying customer 40 requests an identification validation from relying participant 30.
  • step C relying participant 30 checks with root entity 102 as to the validity of issuing participant 10's certificate.
  • step D relying participant 30 receives a response to this check from root entity 102.
  • step E relying participant 30 checks with issuing participant 10 as to the validity of subscribing customer 20's certificate.
  • step F relying participant 30 receives a response to this check from issuing participant 10.
  • step G relying participant 30 forwards the results of these checks to relying customer 40. 4.
  • Fig. 7 Requesting an Identification Validation with Warranty Identification validation with warranty is described in connection with Fig. 7.
  • step 702 subscribing customer 20 initiates a transaction with relying customer 40 (see also A in Fig. 7E).
  • step 704 relying customer 40 requests an identification validation with warranty from relying participant 30 (see also B in Fig. 7E).
  • the request includes the estimated damages to relying customer 40 if subscribing customer 20 is misidentified and a specified period for which relying customer 40 wants the warranty to be valid.
  • relying participant 30 checks with root entity 102 as to the validity of issuing participant 10's certificate (see also C in Fig. 7E).
  • relying participant 30 receives a response to this check from root entity 102 (see also D in Fig. 7E).
  • relying participant 30 checks with issuing participant 10 as to the validity of subscribing customer 20 's certificate and conveys the warranty request to issuing participant 10 (see also E in Fig. 7E).
  • issuing participant 10 checks the validity of subscribing customer
  • step 714 it transmits a message to that effect to relying participant 30.
  • step 716 relying participant 30 forwards this message to relying customer 40, and this scenario ends. Otherwise, if issuing participant 10 agrees to issue a warranty, then the scenario continues with step 718, in which issuing participant 10 updates its total outstanding issuance against its cap to reflect the new activity, and within required time frames, updates collateral with respect to the formula outlined above
  • issuing participant 10 is subject to a warranty issuance limit in total. In addition, however, issuing participants 10 may also choose to establish limits on a per- subscriber basis. This, however, is not a system requirement.
  • step 720 issuing participant 10 transmits its acceptance of the warranty request to relying participant 30.
  • This message includes warranty terms and a contract (see F in Fig. 7E).
  • step 722 relying participant 30 prices the warranty.
  • step 724 relying participant 30 transmits the terms of the warranty to relying customer 40 (see also G in Fig. 7E).
  • step 726 relying customer 40 decides whether to purchase the warranty at the price and terms communicated. If relying customer 40 elects to decline the warranty, then in step 728, relying customer 40 declines the warranty and notifies issuing participant 10.
  • step 730 relying customer 40 returns an acceptance of the terms of the warranty to relying participant 30 (liability remains with issuing participant 10).
  • the acceptance includes the signed warranty contract (see H in Fig. 7E).
  • step 732 relying participant 30 notifies root entity 102 and issuing participant 10, and bills relying customer 40 's account for the total fees associated with the warranty (in some cases, subscribing customer 20 is responsible for charges and the billing structure is different).
  • the notification to issuing participant 10 includes the signed warranty contract (see I in Fig. 7E).
  • Relying participant 30 need not check with root entity 102 as to whether issuing participant 10 is within its limits before the transaction is completed.
  • the reports required by the system inform root entity 102 (independently of issuing participant notification). Those banks over their limits are sanctioned as indicated in this document and the operating rules. In addition controls in the system monitor the limits.
  • root entity 102's warranty cap and collateral manager reflects all warranty transactions each issuing participant has issued that period, and issues a revised aggregate position to the participant 106 and root entity 102.
  • the additional collateral is posted and transferred to the collateral account trustee.
  • the WCCM does an end of period assessment to determine new level of collateral based on market changes.
  • Relying participant 30 can refuse to request a validation or Identity Warranty Assurance (IWA) from issuing participant 10 if legally prohibited from doing so (e.g. to comply with
  • IWA Identity Warranty Assurance
  • Relying customer 40 files a claim within the warranty expiration date (step 804, see also B in Fig. 8F); - Relying customer 40 does not file a claim within the applicable time period and the warranty expires (step 806); or Relying customer 40 files a claim after the applicable time period and the warranty expires (step 808). If, as depicted in step 804, relying customer 40 files a claim within the warranty time limit (along with associated supporting evidence) with relying participant 30, then the system proceeds to step 810 where relying participant 30 notifies the corresponding issuing participant 10 of a filed claim and provides supporting evidence per the contractual obligations with the issuing participant 10 and relying customer 40 (see also C in Fig. 8F).
  • step 812 relying participant 30 notifies both root entity 102, and issuing participant 10's WCCM of the filed claim and the amount of claim.
  • step 814 issuing participant 10 determines whether it will pay. Root entity 102 sets conditions under which claims against warranties shall be paid. The intent is to make sure there is a gold standard for business. Each warranty issuer is provided the latitude to evaluate and dispose of claims using its own procedures. However, minimum standard criteria are established under which claims would be paid. If issuing participant 10 decides not to pay the claim, the system branches to step 816 where issuing participant 10 informs relying participant 30 of its decision.
  • step 818 if relying customer 40 is dissatisfied with issuing participant 10's decision, then the system branches to step 820 where relying customer 40 may initiate dispute resolution/arbitration proceedings (see also E in Fig. 8F). In that event, the collateral is only "released" after the outcome of the dispute resolution process.
  • relying participant 30 may provide a provisional credit/credit enhancement to relying customer 40 in its discretion; if so, relying participant 30 pays relying customer 40 before issuing participant 10 agrees to cover the claim and subrogation allows relying participant 30 to file claim with issuing participant 10, subject to contracts specifying this right. If relying participant 30 provides a credit enhancement to relying customer 40, relying participant 30 is not be required to post collateral as a result.
  • step 814) issuing participant 10 decides to pay the warranty claim, then the system branches to step 822 where issuing participant 10 informs relying participant 30 of its decision.
  • step 824 issuing participant 10 pays the claim to relying participant 30 (see also D in Fig. 8F).
  • step 826 the WCCM monitors the fact that issuing participant 10 has paid the claim, decreases the amount of collateral by amount paid, and also by amount required. If, as depicted in step 806, a claim is not filed within the warranty expiration date, then the system proceeds to step 828 where the warranty expires.
  • step 830 issuing participant 10's outstanding warranty amount is decreased by the expired warranty amount.
  • step 832 at the end of the day, root entity 102's WCCM decreases the collateral requirement to reflect expiration of warranties.
  • step 808 If, as depicted in step 808, a claim is filed after warranty expiration, then the process is the same as if a claim was not filed except that the full value of the outstanding warranty is now reflected back in the WCCM.
  • each LI participant 106 must post collateral in accordance with the criteria established by root entity 102 to be eligible to issue warranty certificates.
  • Root entity 102 is agent for collateral and can direct the collateral trustee to pay relying customer 40. 2. If an issuing participant 10 fails, root entity 102 does not pay valid IWA claims exceeding available collateral.
  • root entity 102 does not advance funds.
  • Root entity 102 determines required collateral of each participant 106 daily; collateral amounts are assigned "haircuts," emulating the CHIPS model. 7. Root entity 102 receives frequent reports from participants 106 on IWAs approved and IWA claims filed to determine collateral required.
  • collateral management system is further described in connection with Fig. 9. As shown in Fig. 9, the collateral management system comprises a collateral custodian or trustee
  • Fig. 9 which maintains custodial accounts 902 for a plurality of participants 106 and whose activities are monitored by root entity 102.
  • the sizes of the custodial accounts are indicated by the grey areas labeled C 1-6 in Fig. 9.
  • the collateral requirement is typically less than the total value of outstanding warranties that have been issued by a participant 106, but the percentage is variable, rather than fixed.
  • Employee 110 also has a smart card reader 1004 attached to his PC 1006 which has installed any necessary software 1008 to use smart card reader 1004.
  • Employee 110 must also load system-enabled application software 1010 on to his desktop 1006 or access it through a browser to a server (not shown). The location of application software 1010 should be transparent to employee 110.
  • Fig. 11 For purposes of this example, assume that the end user is a purchasing manager of an entity desiring to purchase office supplies (an employee 110 of a subscribing customer
  • step 1102 employee 110 starts up his web browser and goes to the site of relying customer
  • employee 110 interacts with the web site, selecting, for example, the supplies he needs. He could also conduct other transactions such as submitting an RFP, placing an order, negotiating a contract, etc.
  • employee 110 When employee 110 is ready to complete the transaction, he indicates this to the system (step 1106). For example, employee 110 may click on a button to indicate that he is ready to submit his order and purchase the supplies.
  • the seller's system may ask employee 110 for other information needed to complete the order, such as ship-to address.
  • employee 110 is then asked to insert his smart card into the reader. Employee 110 places his smart card into the reader and enters his PIN. If the PIN is valid, then in step 1112, the user sees a message saying the system is processing his transaction.
  • step 1114 the employee 110's system software 1010 signs the transaction and sends it with his warranty certificate to relying party 40, in this case the seller.
  • step 1116 relying party 40 then validates the buyer's certificate by sending a message to relying participant 30.
  • step 1118 relying participant 30 sends a message to issuing participant 10 to determine if the certificate is valid, as explained above.
  • step 1120 issuing participant 10 sends a response back to relying participant 30 that says the buyer's certificate is valid. Issuing participant 10 also includes its own certificate in the response.
  • step 1122 relying participant 30 then sends a message to root entity 102 to determine if issuing participant 10's certificate is valid. If all of these responses are yes, then in step 1124, the seller sends a message back to employee 110 that his transaction has been accepted, along with any other pertinent information.
  • the seller's system may have the capability to request an IWA programmed into its software.
  • the warranty is requested and negotiated in the background (as described above) while the buyer waits for confirmation of his purchase order. If problems are encountered as the transaction is conducted, appropriate error messages are displayed to employee 110. These include asking employee 110 to reenter his PIN if it was incorrect. Employee 110 is allowed three tries before he is locked out and instructed to see his business manager to re-activate the card. Note: the number of tries before a user's card is disabled may vary depending on the limits set by issuing participant
  • employee 110 also has the opportunity to perform an identity verification of the seller.
  • the steps in this process are described in connection with Fig. 12.
  • subscribing customer 10 becomes the relying party and requests the seller to send its warranty certificate (step 1202).
  • the steps then followed are similar to those described above.
  • the IWA is not negotiated in the background, but between employee 110, its participant 106, and the seller's participant 106.
  • employee 110 enters the amount and time period for the warranty.
  • this message is sent to issuing participant 10 which sends it to the seller's ("relying") participant 30.
  • employee 110 gets a message back saying the warranty request was accepted and the fee for the IWA.
  • step 1210 employee 110 decides if the warranty terms are acceptable. If employee 110 agrees to pay the specified amount, the system branches to step 1212 where employee 110 sends this response through issuing participant 10 to the seller's ("relying") participant 30. If, however, employee 110 does not want to pay the charge for the IWA, the system branches to step 1214 where employee 110 sends a message back, either declining the warranty terms.
  • Root Entity 102 sits atop the operating model, serving as the main "backbone" for the system. It performs the following critical functions to facilitate seamless operation of the system:
  • Maintains system risk reserve - provides reserve in the form of LC or other guarantees to provide vehicle for managing risk resulting from system failure for which root entity 102 assumes liability.
  • root entity 102 is responsible for managing the root operation and maintaining the integrity of the system.
  • the root functions are performed either centrally or distributed, depending on what the function is.
  • the entities within root entity 102 that are responsible for performing these functions are now described in connection with Fig. 13.
  • root entity 102 employs a private key made up of five root key fragments 1302. Each fragment 1302 is stored on its own token 1304 which is kept secured when it is not being used by a key fragment holder 1306.
  • Each key fragment holder 1306 is responsible for the security of his fragment 1302 and for presenting fragment 1302 to a signing device host 1308 when needed for the approval of certificate authority transactions such as issuance of certificates and CRLs. In particular, when, for example, a certificate is to be signed, key fragment holder 1306 is present to input his token into a signing device host 1308.
  • Key fragment holders 1306 and signing device hosts 1308 are located in geographically diverse locations. The distribution of key fragments 1302 provides a high level of security and protection for the root private key. As further shown in Fig. 13, two key fragment holders 1306 and signing device hosts 1308 are located in a data center 1310 in New York (one PC, one reader, and two tokens), two in a first bank data center 1312 in Frankfurt, Germany (one PC, one reader, and two tokens), and the fifth in a second bank data center 1314 in Hong Kong.
  • Fig. 13 Also shown in Fig. 13 are signing officer stations 1316 that are geographically disbursed as well, with one located at each founding bank 104, for a total of eight signing officer stations 1316. Signing officer stations 1316 are located in a secure location at each of the founding members 104,. Each bank 104, also has two signing officers (SOs) 1318 for a total of 16 altogether.
  • SOs signing officers
  • Signing officers 1318 are responsible for operating signing officer workstations 1316. Each founding bank 104, may, if desired, have a back-up for each SO 1318. Each SO 1318 approves the use of his/her fragment to generate the root key to sign certificates, revocations,
  • the certificate signing process works on the basis of quorums.
  • a quorum of SOs 1318 is needed to approve the use of a fragment 1302 before it can be "released" to the root key generation algorithm.
  • a quorum of fragments 1302 must be approved to generate the root key to sign the certificate. Quorums are established at the time the key is generated. One reject/no vote rejects the whole request.
  • Authorizer 1320 is also shown in Fig. 13. The function of authorizer 1320 resides at founding banks 104,. While this is a required function, it may not necessarily require a dedicated resource. Authorizer 1320 receives and reviews the documentation for root certificate requests, revocations, CRL's, SO maintenance, etc. This person makes the recommendation to SOs 1318 to approve or reject the requests that have been received, and is responsible for ensuring that SOs 1318 have access to documentation (e.g. meeting notes) to facilitate sound decision-making. If sufficient information is unavailable to approve the request, it must be rejected.
  • Registrar 1322 is a root entity 102 employee. This person receives and reviews the documentation for CA transactions such as certificate and CRL requests, and then inputs the request into a CA 1324, initiating the signing process.
  • System administrator 1326 is a root entity 102 employee who manages the system and its databases by doing functions such as: a) Defining and maintaining information about issuers, SOs 1314, and registration authorities 1328 b) Performing backups c) Changing passwords
  • Root CA auditor 1330 is responsible for reviewing CA 1324 and SO 1318 records to ensure that the PKI has not been compromised and procedures are being followed. This review entails verifying the audit records, validating the information in the audit records, and making sure that none are missing. Root CA auditor 1330 must also examine the key pairs submitted for certification, and resulting digital signatures for authenticity before it is released for use. This individual should be within the operations area and differs from those designated within the risk management area of root entity 102.
  • the Root CA 1324 is kept in a highly secure location, with physical and virtual access controls to ensure the system cannot be intruded upon. To minimize the risk of a root key compromise, the root key is never maintained as a whole, but rather in 5 fragments. Three of these 5 fragments constitute a "quorum", or the number of fragments to be used in the mathematical formula that recalculates the root key every time it is needed for a signing operation.
  • the quorum rules are: a) The fragment quorum is 3 of 5. b) An SO can be an SO on no more than 2 fragments. c) It must be possible to sign if 4 SO's are unavailable.
  • LI Participants 106 Following are the various functions performed by LI participants 106,:
  • L 1 is also responsible for reporting warranty status to root entity 102
  • LI participant 106 The functions performed by LI participant 106,'s certificate authority level are similar to those done by the root certificate authority operated by root entity 102. However, the actual roles and responsibilities may be different from those of root entity 102, depending on how each LI participant 106, chooses to implement their certificate authority, including whether or not to use fragmentation for its private key. In addition, the roles described below may vary from participant to participant.
  • One example of the entities within an LI participant 106, that are responsible for performing these functions are now described in connection with
  • a registrar 1402 who is the person responsible for inputting the certificate request into the system. This may be done directly by a customer, by an account officer, or by a data entry person. - Suggested level (if done by bank): Officer or equivalent
  • Fig. 14 Also shown in Fig. 14 is an authorizer 1404.
  • Authorizer 1404 receives from a customer 108 or an account officer the documentation for certificate requests, revocations, CRL's, SO maintenance, etc. He/she reviews the documentation and makes the recommendation to the signing officer 1406, described below, to approve or reject any of the requests that he/she has received. If he/she has does not have enough information to approve the request, it should be rejected. - Suggested level: Vice President or equivalent
  • a signing officer (SO) 1406 who is responsible for operating a signing officer workstation 1408. Based upon authorizer 1404's recommendation, and verification of the request data, SO 1406 approves the use of LI participant 106,'s private key to sign certificates, revocations, CRL's, and SO changes. If a bank chooses to fragment their private key, then multiple SO's and quorums are necessary. Each LI participant 106, develops their own procedures to operate this capability. Suggested level: Vice President or equivalent
  • Auditor 1412 is responsible for reviewing the certificate authority and SO records to ensure that the PKI has not been compromised and procedures are being followed. This entails verifying the audit records, validating the information in the audit records and making sure that none are missing. Auditor 1412 must also examine the key pairs and digital signatures for authenticity. Suggested level: Vice President or equivalent Each Level 1 certificate authority has its own set of operational and security procedures to be followed. At a minimum, they meet the requirements specified in the system operating rules. Each Level 1 certificate authority has haves its own risk management policies and procedures. At a minimum, they meet the requirements specified in the system operating rules. C. Customers 108
  • Root entity 102 is responsible for establishing a system of risk management within the system infrastructure. Management of each system entity is then responsible for ensuring the appropriate controls and structure are operating effectively. To accomplish this, all participants 106 adhere to a clearly defined set of system rules that are structured to reflect the requirements resulting from the detailed analysis of risks, and the identification of controls appropriate to mitigate those risks. Clearly defined contracts are adopted for binding all parties to these rules.
  • the risk management function reports to the CEO of root entity 102 - either within the CEO function or as a standalone position. However, it must have direct accessibility to the audit committee.
  • Root entity 102's risk management policy is to both limit risk and to place responsibility and liability at the point where the risk arises. Therefore root entity 102's risk is limited to the technology and operations directly managed by, or on behalf of, root entity 102.
  • Control Objectives - utilization of expertise in design and implementation, adequate testing before implementation, contingency plans, establishment of security/access policies and controls, independent audits, ongoing monitoring. b) Processing - all failures in actions through error, design weakness, or inadequate policy and procedure implementation resulting in failure to safeguard keys, untimely or inaccurate processing of certificates/updating CRLs, inappropriate certificate usage, or unauthorized transactions.
  • Control Objectives establishment of operating policies and procedures; establishment of limits, ongoing evaluation of risks, ongoing review/monitoring, contingency plans, mechanism to monitor limits/risks related to outside service providers, ability to push down requirement for similar controls to the CA, c) criminal/Illicit Acts - deliberate attempts to/breaches of the technology in processing within the system and/or the failure to detect the occurrence of fraud, resulting in compromise of keys, misuse of certificates, alteration/theft of data, assumption or forged identifications.
  • Control Objectives processing controls, limits, implementation of security, access measures, regular reviews, and ongoing monitoring for adherence. 2. Reputation Risks - negative impact on public opinion and trust by events or publicity resulting in loss of revenue and/or legal action.
  • Control Objectives ability at the root entity 102 level to promptly act to correct or address failures in operations, security, privacy requirements or compliance related to certificates/usage, enforcement against those CA's or service providers who do not perform in accordance with contract, policy terms, and obligations. 3. Regulatory/Legal Risks - requirements are not adhered to or rules are ambiguous and untested - resulting in fines, penalties, or public embarrassment. Control Objectives: establishment of a legal function within root entity 102, agreement requirements that CA's adhere to appropriate laws and regulations, clearly defined rights, obligations, and assumptions of liability within contractual agreements, establishment of ongoing regulatory dialogue.
  • Control Objectives root entity 102 tracking of market, legal, and technology events to enable prompt corrective action, contract limits on financial liability.
  • Control Objectives strong board, project management, and plan implementation and support of senior management within the banks, hiring appropriate expertise into root entity 102 organization, maintenance of adequate reserves and liability insurance at root entity 102 level; requirement that adequate reserves, and collateral be maintained at the CA level, and establishment of the following at root entity 102 level: financial monitoring, mechanism to address need for additional capital, contract limits on liability.
  • Root entity 102 requires periodic external audits be performed of its own operations as well as those of its members. Member reviews are performed at the member's own expense. Root entity 102 also requires that third party technical reviews be performed periodically. All participants 106, as well as root entity 102, are also required to implement internal risk monitoring programs and routines, which specifically address the risks of their operational functions.
  • Root entity 102 reserves the right to request/review audit reports and to evaluate, or further test, to ensure that audit corrections have been made. Root entity 102 also reserves the right to, at its own expense, perform or cause to have performed, any additional audit work considered necessary.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention concerne un système permettant de garantir l'identité d'un interlocuteur relié par un réseau électronique. Ce système se compose d'une entité racine (102) et d'une pluralité d'entités additionnelles (104, 106, 108 et 110). Chaque entité additionnelle (104, 106, 108 et 110) est autorisée dans le système après avoir accepté de respecter un certain nombre de règles de fonctionnement édictées par l'entité racine (102). Les entités additionnelles (104, 106, 108 et 110) sont généralement constituées de participants de niveau un et de participants de niveau deux. Les autorités de certification, qui sont assurées par les participants de niveau un, émettent des certificats numériques qui lient les clients à leurs clés publiques. Les clients système sont également pourvus d'un formateur de demande de garantie qui est adapté à la formulation d'une demande de garantie quant à la véracité de l'information contenue dans le certificat numérique. Le formateur de demande de garantie est également adapté à l'émission de demande de garantie se rapportant au participant de niveau un du client. Les participants de niveau un font vivre une passerelle de messagerie intelligente qui est conçue pour recevoir des messages de leurs clients et émettre des messages à destination d'entités système appropriées. Des offres de garantie sont émises par le participant qui a émis le certificat numérique identifié dans la demande de garantie. On demande aux participants de conserver une relation de collatéralité avec un messager collatéral.
PCT/US2000/003550 1999-02-12 2000-02-11 Procede et systeme de prestation de services, notamment de services orientes certification WO2000048360A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU28787/00A AU2878700A (en) 1999-02-12 2000-02-11 System and method for providing certification-related and other services

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US11995899P 1999-02-12 1999-02-12
US11989299P 1999-02-12 1999-02-12
US60/119,892 1999-02-12
US60/119,958 1999-02-12

Publications (2)

Publication Number Publication Date
WO2000048360A1 true WO2000048360A1 (fr) 2000-08-17
WO2000048360A9 WO2000048360A9 (fr) 2002-05-02

Family

ID=26817834

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/003550 WO2000048360A1 (fr) 1999-02-12 2000-02-11 Procede et systeme de prestation de services, notamment de services orientes certification

Country Status (2)

Country Link
AU (1) AU2878700A (fr)
WO (1) WO2000048360A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002021799A1 (fr) * 2000-09-07 2002-03-14 Bankgirocentralen Bgc Ab Syteme d'identification associe a un reseau
WO2005031625A1 (fr) * 2003-09-29 2005-04-07 Tapsell, Yvonne, Erima Procede et systeme de cryptographie a clefs publiques
US8533118B2 (en) 2008-11-06 2013-09-10 Visa International Service Association Online challenge-response
US10262308B2 (en) 2007-06-25 2019-04-16 Visa U.S.A. Inc. Cardless challenge systems and methods

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5659616A (en) * 1994-07-19 1997-08-19 Certco, Llc Method for securely using digital signatures in a commercial cryptographic system
US5903882A (en) * 1996-12-13 1999-05-11 Certco, Llc Reliance server for electronic transaction system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5659616A (en) * 1994-07-19 1997-08-19 Certco, Llc Method for securely using digital signatures in a commercial cryptographic system
US5903882A (en) * 1996-12-13 1999-05-11 Certco, Llc Reliance server for electronic transaction system

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002021799A1 (fr) * 2000-09-07 2002-03-14 Bankgirocentralen Bgc Ab Syteme d'identification associe a un reseau
WO2005031625A1 (fr) * 2003-09-29 2005-04-07 Tapsell, Yvonne, Erima Procede et systeme de cryptographie a clefs publiques
US10262308B2 (en) 2007-06-25 2019-04-16 Visa U.S.A. Inc. Cardless challenge systems and methods
US11481742B2 (en) 2007-06-25 2022-10-25 Visa U.S.A. Inc. Cardless challenge systems and methods
US8533118B2 (en) 2008-11-06 2013-09-10 Visa International Service Association Online challenge-response
US9898740B2 (en) 2008-11-06 2018-02-20 Visa International Service Association Online challenge-response

Also Published As

Publication number Publication date
WO2000048360A9 (fr) 2002-05-02
AU2878700A (en) 2000-08-29

Similar Documents

Publication Publication Date Title
US9684889B2 (en) System and method for providing certification-related and other services
KR200202696Y1 (ko) 이동통신 전화번호를 이용한 신용결재용 신용결재장치
US7644019B2 (en) Safe transaction guaranty
US6904418B2 (en) Method and apparatus for executing cryptographically-enabled letters of credit
US7599884B2 (en) Programmable joint payment guarantee financial instrument set
KR20000069468A (ko) 전자 거래 시스템을 위한 신용 서버
CN105681301A (zh) 区块链上的结算方法
WO2010022344A1 (fr) Traitement en ligne pour des transactions commerciales extraterritoriale
CA2437507A1 (fr) Procede et systeme servant a executer une transaction entre un client et un vendeur
US7200573B2 (en) System and method for providing warranties in electronic commerce
WO2002035758A9 (fr) Procede pour effectuer des transactions avec une assurance d'identite
US6807635B1 (en) Using digital signatures to validate trading and streamline settlement of financial transaction workflow
Kalvenes et al. Design of robust business-to-business electronic marketplaces with guaranteed privacy
JP2009541818A (ja) ネットワークで金融取引を行うためのシステム及び方法
KR20210052349A (ko) 유가증권의 공매도를 지원하는 방법, 시스템 및 비일시성의 컴퓨터 판독 가능 기록 매체
WO2001018717A1 (fr) Systeme et procede de prestation de services, notamment de services orientes certification
CN114003879A (zh) 资产代理方法、装置、电子设备以及存储介质
JP5592428B2 (ja) ネットワークで金融取引を行うためのシステム及び方法
JP3327257B2 (ja) ネッティングサービスシステム
WO2000048360A1 (fr) Procede et systeme de prestation de services, notamment de services orientes certification
KR20190140869A (ko) 유가증권의 공매도를 지원하는 방법, 시스템 및 비일시성의 컴퓨터 판독 가능 기록 매체
Basu Implementing e-commerce tax policy
KR20110012326A (ko) 일반인이 제공하는 아이디어의 개발 및 투자실행을 위한 사업으로서 회원가입을 통한 거래의 방법 및 그 시스템
AU2004208693A1 (en) System and method for providing certification-related and other services
Casanova et al. THE REGULATORY FRAMEWORK FOR PAYMENT SERVICES IN THE EU AND UK

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

COP Corrected version of pamphlet

Free format text: PAGES 1/25-25/25, DRAWINGS, REPLACED BY NEW PAGES 1/25-25/25; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE

122 Ep: pct application non-entry in european phase
点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载