Methods for operating infrastructure and applications for cryptographically-supported services Number:7,184,988 from the United States Patent and Trademark Office (PTO) owispatent

Title: Methods for operating infrastructure and applications for cryptographically-supported services

Abstract: In an infrastructure in which some of a plurality of entities provide cryptographically supported services, a method of registering a subscriber entity of a plurality of entities at a principal entity of a plurality of entities, the method comprising the subscriber entity requesting service from the principal entity by sending a request message to a registrar entity of the plurality of entities; the registrar entity verifying the subscriber entity and forwarding the request for service to the principal entity; the principal entity storing the forwarded request and transmitting an acknowledgement message to the registrar entity, the acknowledgement stating acceptance and authentication/authorization information that the subscriber entity requires for the requested service; and the registrar entity verifying the authenticity of the received acknowledgement message, and, if correct, forwarding the acknowledgement message to the subscriber entity.

Patent Number: 7,184,988 Issued on 02/27/2007 to Frankel,   et al.

---

Inventors:	Frankel; Yair (Westfield, NJ), Montgomery; Charles T. (Saverna Park, MD), Stubblebine; Stuart (Lebanan, NJ), Yung; Marcel M. (New York, NY)
Assignee:	Certco, Inc. (New York, NY)
Appl. No.:	09/492,534
Filed:	January 27, 2000

---

Current U.S. Class:	705/67 ; 370/235; 370/352; 370/469; 705/1; 707/10; 709/203; 709/217; 709/220; 709/223; 709/224; 709/227; 709/229
Current International Class:	G06Q 99/00 (20060101); H04K 1/00 (20060101); H04L 9/00 (20060101)
Field of Search:	705/1,26,53,67 709/203,217,223-229 707/10 370/469,352,235

---

References Cited [Referenced By]

---

U.S. Patent Documents

	5732400		March 1998		Mandler et al.
	5802497		September 1998		Manasse
	6336095		January 2002		Rosen

Foreign Patent Documents

	0 693 742		Jan., 1996		EP
	0693742		Jan., 1996		EP

Other References

O'Mahony et al. Electronic Payment Systems .COPYRGT. 1997 ARTECH House, Inc. Norwood, MA (pp. 125-143). cited by examiner.

Primary Examiner: Reagan; James A
Attorney, Agent or Firm: Pillsbury Winthrop Shaw Pittman LLP

---

Parent Case Text

---

RELATED APPLICATIONS

This patent application is related to and claims priority under 35 USC .sctn. 120 from co-pending provisional U.S. Patent Application No. 60/117,752, titled "METHODS FOR OPERATING INFRASTRUCTURE AND APPLICATIONS FOR CRYPTOGRAPHICALLY-SUPPORTED SERVICES" and filed Jan. 28, 1999, which is incorporated herein by reference.

This patent application is related to and claims priority under 35 USC .sctn. 120 from co-pending U.S. patent application Ser. No. 09/206,381, titled "RELIANCE SERVER FOR ELECTRONIC TRANSACTION SYSTEM" and filed Dec. 7, 1998, which was a continuation application of U.S. patent application Ser. No. 08/767,257 (now U.S. Pat. No. 5,903,882) which is incorporated herein by reference.

This patent application is related to and claims priority under 35 USC .sctn. 120 from co-pending U.S. patent application Ser. No. 09/026,466, filed Feb. 19, 1998, titled "COMPUTER-BASED METHOD AND SYSTEM FOR AIDING TRANSACTIONS," which is incorporated herein by reference.

---

Claims

---

What we claim is:

1. In an infrastructure in which some of a plurality of entities provide cryptographically supported services, a method of registering a subscriber entity of a plurality of entities at a principal entity of a plurality of entities, the method comprising: the subscriber entity requesting service from the principal entity by sending a request message to a registrar entity of the plurality of entities; the registrar entity verifying the subscriber entity and forwarding the request for service to the principal entity; the principal entity storing the forwarded request and transmitting an acknowledgement message to the registrar entity, the acknowledgement stating acceptance and authentication/authorization information that the subscriber entity requires to obtain or access the requested service; and the registrar entity verifying the authenticity of the received acknowledgement message, and, if correct, forwarding the acknowledgement message to the subscriber entity, wherein the request message contains an indication of a type of service requested by the subscriber entity and contains one or more selected from the following: (a) a unique reference to the subscriber entity; (b) attributes about the subscriber entity; (c) authentication information to be used to authenticate use of the service; (d) transactional verification information; (e) a representation by the subscriber entity agreeing to what the subscriber entity accepts; (f) a preferred service relationship; or (g) a subscriber entity's authenticator.

2. A method as in claim 1 wherein the unique reference to the subscriber entity is at least one selected from (a) the subscriber entity's identity, (b) a pseudonym for one-time service, or (c) a pseudonym for continued use of the service.

3. A method as in claim 1 wherein a session identifier links future responses to this particular request.

4. A method as in claim 1 wherein the attributes about the subscriber entity include: (a) a self-representation; and (b) a third-party representation asserting attributes.

5. A method as in claim 4 wherein said representation and attribute include at least some selected from: (a) an address; (b) employment information; (c) information from one or more other entities needed for service provisioning; or (d) an authorization from another party.

6. A method as in claim 1 further comprising: modifying the registration of the subscriber entity at the principal entity.

7. A method as in claim 6 wherein modification is supervised by one or more authorities.

8. A method as in claim 6 wherein registration modification transactions involve managing capabilities.

9. A method as in claim 6 wherein registration modification transactions involve cryptographic key management.

10. A method as in claim 1 further comprising: moving the registration for service from the principal entity to another entity of said plurality of entities.

11. A method as in claim 10 wherein moving of services is supervised by one or more authorities.

12. A method as in claim 1 wherein the service includes: operating a cryptographically-supported transaction involving the subscriber entity, the principal entity and possibly one or more additional entities.

13. A method as in claim 1 wherein the subscriber entity comprises a plurality of elements.

14. A method as in claim 13 wherein the plurality of elements are associated with an entity.

15. A method as in claim 1 wherein said service is a subset of a totality of services.

16. A method as in claim 15 wherein another subset of the totality of services to the subscriber entity is provided by an entity different from the principal entity.

17. A method as in claim 1 wherein said service is a warranty service.

18. A method as in claim 16 wherein the subscriber entity can modify the subset of totality of services between entities.

19. A method as in claim 17 wherein said warranty service involves correctness of representation of information.

20. A method as in claim 19 wherein said representation of information is at least one selected from: (a) identity information, (b) financial information; or (c) information derived from provision of service within said infrastructure.

21. A method as in claim 17 wherein the infrastructure includes a mechanism to initiate claims against failed warranty.

22. A method as in claim 1 wherein provision of service may involve an additional entity from said plurality of entities.

23. A method as in claim 22 wherein provision of service is split between said principal entity and said additional entity.

24. A method as in claim 1 wherein provision of service by said principal entity on behalf of said subscriber entity is given by said operating infrastructure to an entity within said plurality of entities.

25. A method as in claim 1 wherein said provision of service by said principal entity involves other entities within said plurality of entities.

26. A method as in claim 1 wherein provision of service involves control of access.

27. A method as in claim 1 wherein at least one of said plurality of entities is an enterprise.

28. A method as in claim 1 wherein at least one of said plurality of entities is a financial institute.

29. A method as in claim 1 wherein said principal entity is a group of elementary entities.

30. A method as in claim 1 wherein provision of service by said principal entity is directed by said subscriber entity.

31. A method as in claim 1 further comprising: providing, by the principal entity, at least one of a set of various service transactions to the subscriber entity.

32. A method as in claim 31 wherein said providing involves the certification of digital identities.

33. A method as in claim 31 wherein at least one of said service transactions involves assuring an entity's state.

34. A method as in claim 31 wherein at least one of said service transactions involves assuring financial information.

35. A method as in claim 31 wherein at least one of said service transactions involves assurance of identity and assurance of entity's state.

36. A method as in claim 1 wherein some of said plurality of entities are supervised by one or more other entities in at least one transaction.

37. A method as in claim 1, wherein service involves a fee based on a service agreement and contract.

38. A method as in claim 1, wherein added management and one or more additional entities assure integrity of transactions within the infrastructure.

39. A method as in claim 38 wherein integrity of the management function is enhanced by providing two or more independent reports.

40. A method as in claim 38 wherein the management function controls actions of assurance offering entities on a per transaction basis.

41. In an infrastructure in which some of a plurality of entities provide cryptographically supported services, a method of registering a subscriber entity of a plurality of entities at a principal entity of a plurality of entities, the method comprising: a registrar entity of the plurality of entities receiving a request message from the subscriber entity requesting service from the principal entity; the registrar entity verifying the subscriber entity and forwarding the request for service to the principal entity for storage by the principal entity; and the registrar entity receiving from the principal entity an acknowledgement message, the acknowledgement stating acceptance and authentication/authorization information that the subscriber entity requires to obtain or access the requested service, verifying the authenticity of the received acknowledgement message, and, if correct, forwarding the acknowledgement message to the subscriber entity, wherein the request message contains an indication of a type of service requested by the subscriber entity and contains one or more selected from the following: (a) a unique reference to the subscriber entity; (b) attributes about the subscriber entity; (c) authentication information to be used to authenticate use of the service; (d) transactional verification information; (e) a representation by the subscriber entity agreeing to what the subscriber entity accepts; (f) a preferred service relationship; or (g) a subscriber entity's authenticator.

42. A method as in claim 41, wherein the service includes: operating a cryptographically-supported transaction involving the subscriber entity, the principal entity and possibly one or more additional entities.

43. A method as in claim 41, further comprising: moving the registration for service from the principal entity to another entity of said plurality of entities.

44. In an infrastructure in which some of a plurality of entities provide cryptographically supported services, a method of registering a subscriber entity of a plurality of entities at a principal entity of a plurality of entities, the method comprising: the principal entity receiving from a registrar entity of the plurality of entities a forwarded request message by the subscriber entity for service from the principal entity, the request for service sent to the registrar entity by the subscriber entity and the subscriber entity being verified by the registrar entity; and the principal entity storing the forwarded request message and transmitting an acknowledgement message, the acknowledgement stating acceptance and authentication/authorization information that the subscriber entity requires to obtain or access the requested service, to the registrar entity for verification by the registrar entity of the authenticity of the received acknowledgement message, and, if correct, forwarding the acknowledgement message by the registrar entity to the subscriber entity, wherein the forwarded request message contains an indication of a type of service requested by the subscriber entity and contains one or more selected from the following: (a) a unique reference to the subscriber entity; (b) attributes about the subscriber entity; (c) authentication information to be used to authenticate use of the service; (d) transactional verification information; (e) a representation by the subscriber entity agreeing to what the subscriber entity accepts; (f) a preferred service relationship; or (g) a subscriber entity's authenticator.

45. A method as in claim 44, wherein the service includes: operating a cryptographically-supported transaction involving the subscriber entity, the principal entity and possibly one or more additional entities.

46. A method as in claim 44, further comprising: moving the registration for service from the principal entity to another entity of said plurality of entities.

---

Description

---

BACKGROUND

1. Field of the Invention

This invention relates to cryptographic and distributed trust mechanisms for automatic service provision via computer and communication networks.

2. Background & Summary

Basic cryptographic infrastructure techniques and methodologies are known. These techniques and methodologies include Certification Authorities (CAs) and other Trusted Third Parties. The notion of providing reliance to transactions in the context of an infrastructure supporting assured transaction between users is described, for example, in co-pending related U.S. patent application Ser. No. 09/206,381, titled "Reliance Server For Electronic Transaction System" and filed Dec. 7, 1998, which was a continuation application of U.S. patent application Ser. No. 08/767,257 (now U.S. Pat. No. 5,903,882), and in related U.S. patent application Ser. No. 09/026,466, filed Feb. 19, 1998, titled "Computer-Based Method And System For Aiding Transactions," where an infrastructure for provision of the reliance and assurance was identified.

The infrastructure is generally composed of many local representatives that are system's entities when infrastructure is viewed as a system. The infrastructure is established, e.g., to register users and business clients so as to support assuring and providing warranty to support transactions between the business entities and users.

This invention provides complementary methods for organizing, maintaining and dynamically managing the infrastructure as well as further methods for the applications involving the operation of the infrastructure and of its users. This invention also provides dynamic tools for a multi-enterprise, multi-entity infrastructures and further involves methods of their organization, set-up, maintenance. This invention also provides methods for dynamic management of the relationships between the entities and the various users of the infrastructure. The exact nature of maintaining the linking and the mechanisms to support the linking of locations into an infrastructure are also provided.

The present invention transforms the basic cryptographic tools, security technology such as access control and delegation mechanisms, data base technologies as well as computer, networking and the World Wide Web technologies, into a coherent service where providers are organized, dynamically maintained and operate with clients with other business institutes and work amongst themselves.

Maintaining and operating dynamically of a service using electronic transactions needs to be trustworthy, secure, private as well as robust is typical in sensitive services such as financial, banking, insurance, medical, international commerce and other commercial areas, export/import business, media and information services, services where political constraints are crucial, and many other areas which may require support to achieve the required trust, support, security and other assurances. These numerous areas require the infrastructural support and dynamic maintenance and operation as provided by the present invention.

This invention employs basic cryptographic and security and integrity mechanisms such as digital signatures, electronic contracts and agreements, digital certificates, electronic documents messaging and reporting, encryption, key escrow and recovery, access-control, delegation techniques and communication protocols to provide an infrastructure and applications required to render on-line services.

This invention also provides services that are associated with endeavors that require trust and accountability for transactions conducted and where there are numerous entities involved.

In another aspect, this invention involves the deployment of methods and mechanisms to establish a service infrastructure of system entities and maintain the relationships among them.

Further, this invention involves methods for enrolling users and enterprise representatives as subscribers to the services provided.

This invention also involves methods for operating and supporting the service provided among the system entities themselves and among the system entities and organizations not enrolled within the system.

This invention involves methods to regulate and monitor service transactions conducted with subscribers of the system.

This invention incorporates methods that dynamically maintains and expands all relationships among the system's entities as the system evolves and changes.

Further, this invention provides various methods that are interrelated and connected to assure a coherent, flexible, trustworthy and robust service providing mechanism.

The systems and methods of the invention employ a trustworthy, flexible and robust services involving trust and assurance of transactions conducted. The system and method are useful in various areas where certain commercial and financial activities are moved to an electronic network domain such as the Internet. Typical areas where cryptographic and trusted control features of the present invention may be needed are: financial services, insurance services, medical services, various government, notary services, commercial services, news, information and media services, political consulting services, government services, arbitration services, international market services and legal services.

For example, the methods of the invention are especially useful for handling multi-enterprise organizations and dealing with numerous users and enterprises.

The invention identifies the basic cryptographic, computer and communication technologies and messaging supporting techniques required to support the service mechanisms. The invention provides methods for accomplishing trustworthy services involving flexible service procedures.

The invention is in the area of cryptography and distributed trust mechanisms in connection with automatic service provision via computer and communication networks. It deals with the use of basic cryptographic and security and integrity mechanisms such as digital signatures, electronic contracts and agreements, digital certificates, electronic documents messaging and reporting, encryption, key escrow and recovery, access-control, delegation techniques and communication protocols to provide an infrastructure and applications required in the service provision. The service is associated with an application area where trust and accountability of service transactions is required and where there are numerous entities involved. The invention involves and provides methods and mechanisms for establishment and maintenance of a service infrastructure of system entities and relationships among them. It further involves and provides methods for handling of users and enterprise representatives as subscribers to the service. The invention also involves and provides methods for operation and support of the service among the system entities themselves, and among system entities and other organizations. The invention involves and provides methods regarding service transactions with subscribers. Finally, the invention provides methods for dynamic maintenance of all relationships among the system's entities as the system evolve and changes. The various methods are interrelated and they are connected to assure coherent, flexible, trustworthy and robust service mechanism.

Such trustworthy flexible and robust services involving trust and assurance of transactions are envisioned to be useful in various areas where certain commercial and financial activities are moved to an electronic network domain such as the Internet. Typical areas where cryptographic and trusted control may be needed are: financial services, insurance services, medical services, various government, notary services, commercial services, news, information and media services, political consulting services, government services, arbitration services, international market services and legal services. The methods are especially useful for multi enterprise organizations, dealing with numerous users and enterprises. The invention identifies the basic cryptographic, computer and communication technology and messaging support required to underlay the service mechanisms. It suggests methods for accomplishing trustworthy service involving flexible service procedures.

BRIEF DESCRIPTION OF THE DRAWINGS

The objects and advantages of the invention will be apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings, in which the reference characters refer to like parts throughout and in which:

FIG. 1 depicts a primary registration protocol according to embodiments of this invention;

FIG. 2 depicts a service migration and example according to this invention;

FIG. 3 depicts a backend infrastructure according to embodiments of this invention;

FIG. 4 depicts a registrar infrastructure according to embodiments of this invention;

FIG. 5 depicts operating a combined transaction within the infrastructure and example according to embodiments of this invention; and

FIG. 6 depicts operating a combined transaction with monitoring service according to embodiments of this invention.

DETAILED DESCRIPTION

Entities and Relationships

When a cryptographically-supported service is initialized, various entities are identified as the service providers. The entities may be certified as such and organized under a so-called service organization. Alternatively, the entities may be endorsed by some organizations or be certified by some other mechanism. There needs to be cryptographic means to achieve the acquisition and presentment of credentials for a service provider over a network. The credentials may be temporal or may change otherwise according to different rules. This invention provides a mechanism that represents such set-up and maintenance of service provision license. In general, in all these mechanisms, this invention provides for the ability to identify the authorities that can assure the certification and credentials of a principal (service provider). The numerous variations of organization may change as the system continues, due to changes of scale, regulations, and other characteristics of the service. This invention provides methods for long term maintenance of such changing environment.

The various entities within a system may have certain relationships, some bilateral and some public. These relationships have to be maintained with integrity. Long-term and short-term changes in these relationships have to be validated and synchronized in order to assure globally known structure. An example of a known structure is a hierarchy of certification authorities in the area of digital signatures and public keys; other organizational structures are possible. Other examples include: a division within a company that provides a sub-service; or a department within government performing a function which is globally recognized (for example, passport issuance--a passport issued by the Department of State is good for all state and country identification purposes).

Other relationships include service relationship where the receiver of service may move. For example, a customer may move between banks, thereby rolling accounts between banks. Some relationships are based on contracts signed between the parties. Some relationships are defined as participation in a system such as payment systems where a party can pay to another party or via their banks or organizations. This invention provides for the electronic maintenance of such relationships.

Other elements in the system are users that are individuals or groups of users. Users can be individuals or enterprises or enterprise representatives. They can be a group or can be organized as groups. Users and entities have long-term attributes and may be granted capabilities that may be later taken away. The distinction between users and entities that are enterprises is artificial since some of the users themselves may be enterprises and they may just use the infrastructure and applications to execute transactions and derived transactions for supporting the service.

The relationships between entities are in a general context of a service that may be associated with a sector of the industry such as financial, insurance, medical, government, and the like, or that may be an interdisciplinary service. The nature of a service may involve a suite of applications associated with the discipline, industry or sector. For example, and not to indicate restriction on the service, it can be assumed that the service supports transactions involving transfer of money and other financial instruments between users. Another example is the provision of a warranty regarding the identity and conditions associated with clients, guaranteeing payments and otherwise taking responsibility for completion of the transaction and perhaps take liability or other involvement. A further example of a service may be associated with consulting consumers about financial and commercial transactions. In addition to the financial area examples where banking and insurance are major services, many other areas of service can be implemented using the infrastructure and applications described herein.

In preferred embodiments of this invention, entities are assumed to have computer and communication equipment as well as software for performing transactions, communicating, preparing reports and documents and other computational and office support for conducting transactions.

Transactions and Processes

This invention provides methods to register users into services, and to allow them by authorization to be associated with service characteristics. This implies certain capabilities which are different for different users. Methods are also provided to allow for the registration to be changed/terminated (recording termination in all relationships are important events). Both the capabilities and the association of users with entities and their relationships may be changed. Methods are provided to manage the relationships between users and the service system. This management is trusted and provides a binding that is recognized by certain system's entities. The binding can be to the user or to the user's role or it can be anonymous, many variations are possible within the methods provided by this invention. Users and users' groups may belong to one enterprise and may be registered at another enterprise. The registration and maintenance process may be performed individually or in bulk groups.

The various elements in the system undergo various registration processes. First, the principals and registrars need to register and then other entities representing organizations will register. Note, one can employ one of the many know registration processes/mechanisms to allow registration of entities into a cryptographic or transaction systems.

To define capabilities or user characteristics, one needs to look at the nature of the service. In financial services the capabilities typically involve certain credits, payments, and authorized spending amounts. Additionally, capabilities may be related to level of credit, assurances, guarantees, and limits associated with users and organizations groups and entities. In other services, capabilities may be associated with access to a certain content, software or computing server. Capabilities may involve various authorizations associated with the characteristics and the history of a user and involve evaluation of risks associated with the user (for example, allowed medications in the medical area). Some capabilities are fixed (for example, attributes) or long-term, and some dynamically change over time (for example, behavior anomaly detection when users misbehave). Managing the capabilities and characteristic of entities and users are methods to be enforced.

Relationships and capabilities can be derived from the system's procedures, rules and regulations. Various representation methods are known to deal with generic rules and regulations and ways to enforce them. These rules are incorporated within the cryptographic and security infrastructure mechanisms.

Transactions are defined within the relationship structure between users and entities and between entities and entities, and between entities and authority organization. Users are getting service via transactions with various entities. A transaction is determined based on long-term relationships as well as on temporal constraints (for example, network connectivity). Transactions may involve numerous entities within the infrastructure. A user may direct a service request to some entity with whose organization that user is involved, this entity may deal with the service request or may forward it (or both), it may also create further infrastructure transactions. Finally the transaction is processed, risk management and decision making as well as data base maintenance and update take place, messages are exchanged and the service is provided. It may either end electronically or may trigger further operations which may be non-electronic.

Derived transactions are spawned on-line to support a basic transaction (for example, re-insurance, underwriting and aggregations). These derived transactions involve the on-going business and dealings between the entities. They may involve third parties who may deal with certain conditions of the user (provide insurance for a transaction) or parties which may provide additional service (affinity organizations). Entities may aggregate transactions or representations of transactions and deal with them as another transaction. Arbitration services may be invoked to provide anonymity and other assurances. Requirements to include on-line assurances (forcing the user to re-negotiate its status with some party) may be required. Other derived transactions, some of which are visible and some are transparent to the users, may be invoked. Note that the derived transaction may take the same structure as an initial transaction. For example, if the initial transaction deals with granting a warranty, the derived transaction may start by the warranty grating entity, where it is seeking collateral support or coverage or ancillary means for extending the required warrantee safely. An insurance transaction may result in a re-insurance transaction. These examples are typical and not exclusive to the nature of relationships between transactions and derived transactions.

Maintenance transactions may be required to support the infrastructure of entities and users. Reporting and messaging, as well as auditing and filing are part of the on-going support that is generally done off-line. Payment and accounting methods or triggering of payments outside the system, are included as part of the transactions. Risk management techniques, expert systems, artificial intelligence methodology, statistics and data mining may be used, for example, for anomaly detection regarding user behavior.

Numerous other maintenance procedures are possible, such as reiterating capabilities and refreshing cryptographic tools and keys using many of the key management and protocols available in the cryptographic literature, for example, in Cryptography and Data Security by D. Denning, and in Applied Cryptography by B. Schneier, both of which are incorporated herein by reference.

Technical transactions are added transactions that involve the overhead resulting from securing systems, assuring their availability, operation condition and integrity. Technical transactions involve cryptographic logging, integrity checks, secure messaging and other cryptographic mechanisms known in the art. Technical transactions involve transaction commit mechanisms for maintaining distributed data bases and fault tolerance communication protocols.

Security, Integrity and Privacy Considerations

Methods are provided to assure that entities and records and messages are protected within well-defined domains. Even service providers may not get certain information out of certain protective devices within their computer and network components. Privacy is important to protect both individual and businesses. Anonymity may also be important to protect. This invention provides methods to be included in the various component designs and transaction designs that will provide this secrecy, privacy and anonymity. Management of privileges is inherent to the process of jointly serving and getting service.

The operation of aspects of this invention assumes that cryptographic technologies using symmetric and asymmetric techniques are available, as well as access-control technology.

Furthermore, in communication it is assumed that each message that needs to be secured is encrypted by a key. The key is either shared by the sender and the receiver or derived from a key exchange protocol (for example, the Diffie-Hellman key exchange where one or both parties publicize a public key and the parties can derive a shared key). Further, messages that need to be signed for authenticity and proof of origin, are signed by the sender. Shared cryptographic information may be used for binding and connecting messages, logging and monitoring of messages.

Within a context of message exchange (a transaction), messages may be tagged by a transaction or session identifier, the participants, and the content of historic messages. The state of users may also be part of the tag. Using a tag and the available cryptographic tools (keys and shared random strings), the message can be authenticated as bound to the current context. Mechanisms for authentication are known in the cryptographic art. Such binding of messages assures the integrity of the entire transaction. Examples of such usage of cryptography for assuring transactional integrity are given in U.S. patent application Ser. No. 09/026,466, Frankel et al, (hereinafter "Frankel") which has been incorporated herein by reference.

In the description of protocols and procedures in the context of this invention, such cryptographic tools are assumed to be included in each message. The exact details of how to achieve it may follow Frankel, or may use other cryptographic methods to achieve transactional integrity and secrecy. The exact description of cryptographic integrity and binding fields is omitted where it is apparent to those skilled in the art how to employ, e.g., the methods of Frankel in the context and protocols of this invention.

Other cryptographic subsystems may be added to messages or may follow as sub-protocols, for example an electronic payment system that follows a successful transaction.

DESCRIPTION

The Service System Components

This section describes the basic primitives that are used throughout the discussion of this invention. First define some terminology is defined concerning the participants (entities) of the system and operations within the system. Capability: A form of authorization. Attribute: a feature associated with a named object. Subscriber (or user). A system's entity (or a group of entities) that is to obtain some form of capability (that is, enrollment to an offered service) or attribution (for example, assignment as a role such as purchasing manager). Group: a set of system entities (for example, subscriber group a group of subscribers, registrar group a group of registrars). Supervisor: a system entity that is able to request changes for a user or group of a capability or attribute or the characteristics of entity's service. Manager: a system entity that is responsible for maintenance and control of operations. Auxiliary Agent; a system entity that is responsible for secondary and aid operations (e.g., time-stamping etc.). Registrar: The systems entity facilitating the issuance of capabilities and/or attributes on behalf of a principal authority. Principal Authority (or principal): The systems entity with authority over some attribute or authority to delegate some capability to a peer registrar. Proxy/Interface: An entity in the system acting on behalf of other entities either as a conduit or as a legal representative of actions of entities. Transaction: An interchange for a service related to a subscriber. It is based on the nature of the service. Derived Transaction: An interchange which was initiated by another transaction. "Transaction" and "derived transaction" are used interchangeably herein. Infrastructure Relations: There are sub-structures of the infrastructure that represent relationships amongst entities. For example, a certification hierarchy (within a digital certificate) may represent a substructure, certain relationships amongst entities are possible, for example a "preferred service relation" defines a priority structure that an entity prepares to direct certain service provision.

For cryptographic operation, a group is an abstraction defining a set of system entities or grouping of entities and already existing groups. Groups may consist of the same type of entities or mixed types. Of interest here are groups that consist of entities with some form of relationship (for example, entities from same company, same role, entities within a range of allowed liability amount, etc.). Note that there might be multiple supervisors for any group where different types of supervisor performing different tasks. For example, the registrar may also be thought of a special type of supervisor for a user or group but there may be other supervisors that deal with risk management for the same group.

From a cryptographic perspective, the system can be considered as entities as having both master keys and transactional keys. The master keys are only used to refresh transactional keys therefore the master keys are not used often and have limited functionality. Hence master keys are less prone to compromise. Note that any type of entities can potentially have a hierarchy of keys and it may be that the hierarchy is more than two levels. For instance, there may be one or more master keys to establish sub-master keys for different types of transactions and these sub-master keys establish the transactional keys. As noted above, the cryptographic portions of messages providing the various security and integrity functionality are added using the various keys.

Other transactional verification information such as transaction counts and state may be shared by two system entities to verify the validity of a transaction and to test for compromise of the keys. This sharing is used as additional protection included with authentication. For instance, if two parties who communicate regularly over a cryptographic authenticated channel maintain a transaction count, when a transaction count becomes out of synch it is an indication that the authentication key(s) of one of the parties has been stolen. User's keys and transactional verification information such as counters and state may be stored on physically secure devices such as a smartcard.

The above terminology is generic and covers the minimal function of each entity (or a function of a role of an entity in cases where an entity plays various tasks within the system).

Subscriber Registration, Capability Request and Contract Signing

The process of issuance of a capability or attribute for a subscriber on behalf of a principal with a registrar is described here. This section first describes the registration protocol with the incorporation of a registrar when the registrar is not used then for security reason there should be a physical means in which to authenticate the communication between subscriber and principal. As noted above, various entities are registered for the service with other entities. This section describes a registration mechanism which is an embodiment illustrating these types of registration. In fact, a registrar may be registered with a principal, an entity may be registered with a registrar or with another entity, a business unit may be registered as a client with an entity, a list of users or individual users may be registered with an entity, a proxy may register an entity with another entity.

As an example, during a bootstrap before subscriber registration occurs, the subscriber (similarly, principal) obtains possession of the public signature key or private authentication key of the registrar through some authenticated channel. This is the basic setup subroutine that exists in many cryptographic protocols necessary to establish authenticated cryptographic security channels.

The Registration Protocol

FIG. 1 depicts an exemplary registration protocol according to embodiments of this inventionError! Reference source not found. This section describes the message flows 1, 2, 3, 4, and 5. Note that all or parts of the messages may be encrypted. Encryption may be for (but not limited to) the purposes of session confidentiality between the subscriber and register. However, some message elements may be encrypted (under a key not known by the registrar) and passed to the principal. Any and all message elements may be encrypted.

The following acts are performed for provisioning of a service to a subscriber. (Note, the subscriber represent one or many systems entities.) Furthermore, before the beginning of this protocol there may have been a negotiation protocol between the various parties (subscriber/registrar, subscriber/principal, registrar/principal) in which terms of service are agreed upon.

The Subscriber Requests Service (Message Flow 1).

The subscriber sends a request associated with itself to the registrar. The request associated with message flow 1 contains: An indication of the type of service requested (for example, to "subscribe" to an initial or certain additional services, to "modify" parameters associated with subscribed services, and to "unsubscribe" from services).

Optionally the request contains one or more of the following: A unique reference to the subscriber, and/or session (for example, this can be the subscriber's identity, a pseudonym for one-time service, or a pseudonym for continued use of the service, etc.). The session identifier may link future responses to this particular request (or set of requests) which may include context information for subscriber when acknowledgement or refusal (rejection) message is received. Attributes about the subscriber or subscription group such as: (a) self-representations and (b) third-party representations asserting attributes such as Addresses (for example, virtual address, physical address) Employment information (for example, employer) Information from other entities needed for service provisioning (for example, employee number from staffing office, etc.) Authorizations from other parties (for example, third-party approval for service, delegations, electronic "tickets"). Authentication information. This is information used by the service to authenticate use of the service. This may include public keys, shared secrets, and elements of a hash chains. It may also include other information, such as a round of a Diffie-Hellman key exchange, which can be later used to derive a secret value (for example, a key). Transactional verification information such as transaction counts and state that may be used by the principal to verify the validity of a transaction. (This information may be encrypted to prevent the registrar from making transactions as the subscriber.) The validity assures that the transaction is correct within a stream of other transactions. Representations by the subscriber agreeing to what the subscriber accepts (such as the terms and conditions of the service, agreement to fees for services). Also, payments may be sent. Preferred service relationships, to guide the service provider in what way to search for optional sub-services. Other infrastructure sub-relationships may be provided to guide the service provision. Other information needed by principal(s), registrar(s) and other entities for acceptance of the request. Other information needed by principal(s), registrar(s) and other entities to provision service. Any other information needed by principal(s), registrar(s) or other entities (for example, auditor). Subscriber's authenticator: which validates the current message and its origin.

Registrar Forward Request (Message Flow 2).

Upon verifying the subscriber (either via the authenticator of the request or other process such as in person request), the registrar forwards (with message flow 2) the request and any modifications to the principal. The registrar may verify the subscriber's request by itself or employing derived transactions with other parties. The forwarded request is authenticated by the registrar. The forwarded request may include information such: as: The information (or subset) from flow 1 sent by subscriber to registrar. In addition the following may be sent: identity of registrar registrar's request identifier to link future responses to request which may include message context information for subscriber when acknowledgement is received Additional requested attributes and capabilities provided by registrar modifications to subscriber's requested capabilities, attributes and contract Identity of principal(s) accepted for request by registrar. Public and/or private authentication keys to be used by the principal to verify future registrar's interaction. Or other cryptography related information. transactional verification information such as transaction counts and state that may be used by the principal to verify the validity of this request. This information may be encrypted to prevent the registrar from making transactions as the subscriber. allowed (accepted) cost for registrar's, principal's and other entities services contract for service stating what the registrar accepts registrar's request identifier to link future responses to this particular (or set of) request which may include context information for registrar when acknowledgement or refusal (rejection) message is received. Other information needed by principal(s), registrar(s) and other entities for acceptance of request (for example, preferred service relationships). Other information needed by principal(s), registrar(s) and other entities to provision service Any other information needed by principal(s), registrar(s) or other entities (for example, auditor). registrar's authenticator (either private key authentication or public key signature) of the above information

In case the registrar does not accept the request, it transmits (as message flow 4) an (authenticated) refuse message back to the subscriber with a reason for the refusal and supporting information, an identifier for rejection and the request (or a subset of the request) or hash of the request. There may also be a case in which the registrar may charge for its service, in this case there maybe a negotiating protocol in which the registrar and subscriber negotiate a cost.

The Principal Initiates the Response

Next, the principal initiates the response by storing the request after verification of the authenticity of the forwarded request (message flow 2) by the registrar. The principal may also verify the request of the subscriber if it has the capability to do such (that is, it has verification keys of subscriber). The principal may also perform other verifications that may be necessary before providing the capability these may include but are not limited to policy check, criminal record checks, bank account verifications, D&B ratings, employment verification, credit limits on accounts, etc. This may be done using a derived transaction. These third parties are essentially auxiliary agents and registrars that are not requesting a capability or attribute directly but rather just attesting to identity, attributes, and/or capabilities of the subscriber.

The principal now transmits to the registrar (as message flow 3) an acknowledgement stating acceptance as well as authentication/authorization information that the subscriber requires for the requested capabilities. Some of the additional information needed by subscriber to be able to use capability are policies, public key certificates of the subscriber as well as other entities in the system, instructions etc. may also be included. The use of a new request identifier, or previously generated one, to link future responses to this particular request may also be included in the message. Similarly unique cryptographic keys linked to the transaction, rather than identifiers may be used.

Other information that may be provided are accepted costs and accepted contract. This message (message flow 3) is authenticated for the registrar to verify and for the subscriber to verify (if the subscriber has a verification key of the principal).

If the principal refuses to provide the capability, it may send an authenticated refusal message with the reason for refusal as well as message flow 1 and/or message flow 2 (and/or their hashes) to the registrar or directly to the subscriber. The registrar can use the refusal protocol described in flow 2 to send to the subscriber.

1.1 The Registrar Verifies the Authenticity of the Received Message

The registrar verifies the authenticity of the received message (message flow 3) and, if correct, forwards acknowledgement (accept) message to the subscriber. The registrar's acknowledgement may include additional information such as its final cost for its service.

Message flow 5 1. Even though the principal initiates the request, it may be that the user must perform other operations to obtain the request to activate the service. The subscriber, after performing these operations, may not have obtained its requested capability at this time. The subscriber may be required now to perform additional communication with the principal to obtain its full capability. Additional information may have been sent to the user in the acknowledgement messages to be used for the activation procedure.

Note that the registrar may be an optional entity in the system. In the case that the principle can act in the responsibilities of the registrar then a more simplified protocol can be implemented by leaving the registrar's information blank.

Note that the above protocol could incorporate multiple registrars, principals and subscribers as well as throughout our discussion. Some examples are provided:

Multiple subscribers: It may be that the capability or attribute is based on a group. For example, a capability which can only occur upon the signatures of each of at least a pre-specified quorum from a defined set of subscribers, or a threshold signature scheme which makes a single signature from multiple subscribers (see, for example, "The handbook of Applied Cryptography" by Menezes, van Oorschut and Vanstone, which is hereby incorporated herein by reference). To allow for this the registrar may deal with each of the subscriber and send one batch or multiple requests upward. Another mechanism is that the requests are sent individually to the principal (via a registrar if desired) and the principal manages the requests when the necessary number based on policy and capability are received.

Multiple Registrars: A registrar may only be able to or allowed to request for specific attributes and capabilities. In such a case, there may be a need for multiple registrars to make a request such that the composition of the requests made provides for the composition of the capabilities. That is, if a user wants X which registrar A can request and the user wants Y which registrar B can request, then the user works with A and B to make requests to the principle. These requests can happen in a serial order, from A to B to the principal (similarly B to A); another alternative is when all requests each appears at the principal that combines all the requests into a combined capability/attribute. Also a registrar may be attesting only to a specific verification it performs rather than the capability it requests and the principal based on some policy requires more than one registrar to register a subscriber.

Multiple principals: in case a principal can not provide sufficient capabilities or attribute, and multiple principals can. This can be for example a group of multiple underwriters (who want to share the risk). Another example is for assuring financial and identity information associated with an entity: one principal may deal with identity verification whereas another one my deal with financial data (this separation may be a result of operational and privacy constraints).

For simplicity of discussion, these multiple entity protocol are allowed in any of the discussion discussed even when not discussed explicitly.

The registration may have a few stages: it can start with a negotiation where one is not "actually registers" but rather gets response with terms and conditions. It can follow with an "enrolment registration" where the entity is registered and can then be followed by an "activation registration" where the service actually starts. The various stages may be needed to assure integrity and allow for checking and verifications.

Note that a user may register with a proxy server as a service.

Note also that a proxy or a representative of a group may submit "in bulk" a group list for registration.

Many times the registration process is bilateral. Namely, whereas one side is assured by the registrar to have the capability to provide services, the other side is assured to be a credible service receiver. For example one side may request financial services, it has to be assured that the organization it is registered with is capable and knowledgeable in the area. On the other hand the organization has to know the background and some financial history of the requestor of financial service. Bilateral matching capabilities (receiver of credit against an issuer of credit) can be typical in many scenarios.

Finally, note that a response at the end of registration and other capability issuance procedures may be a microprocessor, diskette, or smartcard, or an information printed on paper which are sent out of band to the user. Many other variations are possible, known in the art, and are not excluded from this invention.

Contract Signing

The registration protocol of FIG. 1 can be used to provide for a contract signing protocol via a third trusted party. The protocol provides for fairness and mutual commitment by both parties signing.

The registration protocol is performed as the message flows of FIG. 1 to negotiate an agreement between principle and subscriber where the contract can be, say, an attribute or other information in the request. When the registrar observes that both parties agree (by noting that the principle acknowledged message), the registrar then has each party send an encrypted signature of the contract. Note that neither party can read the other party's signature but the registrar can. The registrar then verifies the signature of each party with the agreed upon contract. If both signatures verify then the registrar transmits, the principals signature to the subscriber and the subscribers signature to the principal.

This protocol is quite flexible. The protocol described here can be modified for more than two contract signers. It is also possible for the subscriber and principal to sign different documents that are mutually agreed to.

There exist other contract signing protocols which exists in the art that are usable in the architecture.

Modify Capability or Attribute

Similar to the registration protocol that adds a capability it may be the case that a modification, including deletion, of the capability or attribute is necessary.

One mechanism is for the principal to make a modification without the subscribers permission and an authenticated notification sent to the subscriber. The modification may be permanent or temporary and the notification can include Scope of the modification Coverage dates Reason for modification Any additional information (for example, keys, etc.) needed by subscriber to perform transactions Authenticator of all the above

The modify operation may be initiated by the user. There are several mechanisms to perform the modify. A request to the principal through a registrar for a modification can be performed similar to a registration primitive by marking the registration request flag as a "Modify" or "Unsubscribe" rather than "Register". Generally, the registrar is a supervisor for the group. Another mechanism exists, when the user's verification key is held by the principal. In this case the user can make a request directly using the user's authentication key if the principal allows for the modify without a registrar. A modification operation may also be initiated by a supervisor of the user or group as well as by a proxy on their behalf.

The protocol flows carrying the information may follow the structure of the protocol of FIG. 1.

Refresh of Authentication Information or Other State Information

From time to time the information stored by the subscriber and principal may need to be refreshed. Consider the system as having both master keys and transactional keys. The master keys are only used to refresh transactional keys therefore the master keys are not used often with and have limited functionality. Hence they are less prone to compromise. Refresh may be a mechanism to maintain capabilities, where reiterating a capability every so often maintains its validity.

This can be achieved by the principle and subscriber both establishing master keys as well as state information during the registration protocol or a subsequent protocol. Then using the established master encryption and/or authentication keys, the subscriber can perform an encryption over an authenticated channel in which the subscriber, registrar or both transmit information privately which can be used to establish new transaction keys as well as state information. Using an authenticated public key exchange protocols such as a Diffie-Hellman key exchange, private channels are not necessary. Also authenticated channels are not necessary here when private keys are shared by each party. A private function is performed on a nonce to generate new transaction keys as well as new state information then each party proves that they know the new transactional keys and state information before discarding the old key and state. Numerous other methods for refreshing information are available in the art.

Pseudonyms

It may be the case that a subscriber will use a pseudonym for later transactions. In such a case there are multiple methods that can be incorporated into the registration protocol.

A pseudonym may be encrypted as the identity of the user with an encryption key that the principal can later use to decrypt and obtain the true identity. This may be part of the registration flow sent from subscriber to registrar and then to principal. It may also be agreed to after the