WO2003009512A2 - Trust management - Google Patents
Trust management Download PDFInfo
- Publication number
- WO2003009512A2 WO2003009512A2 PCT/GB2002/003258 GB0203258W WO03009512A2 WO 2003009512 A2 WO2003009512 A2 WO 2003009512A2 GB 0203258 W GB0203258 W GB 0203258W WO 03009512 A2 WO03009512 A2 WO 03009512A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- trust
- rules
- community
- entity
- entities
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
Definitions
- This invention relates to methods, systems and apparatus in the field of trust management, electronic security etc.
- Public key cryptography is one important technique used to facilitate these transactions.
- the introduction of public key cryptography and infrastructures to support it there have been problems due to a lack of interoperability.
- a trust domain is thought of as being brought about by a body (which itself might also be termed a trust domain) which acts as a source of trust for those sets of individuals and/or organisations that are encompassed within the domain.
- An organisation that issues digital certificates to its employees may be seen as establishing a trust domain. If that organisation then issues digital certificates to other entities, they may then also be seen as being a part of its trust domain.
- a method for managing interactions between entities each belonging to a respective one of a plurality of different trust domains comprising the steps of: creating a trust community which encompasses the trust domains; and controlling the activities of entities within the community.
- a method for managing interactions between entities each belonging to a respective one of a plurality of different trust domains comprising the steps of: creating a trust community which encompasses the trust domains; allowing each trust domain to define its own security policy rules; and providing a central body to enforce the security policy rules of each trust domain within the community.
- a method for facilitating interactions between entities each belonging to a respective one of a plurality of different trust domains comprising the steps of: creating a trust community which encompasses the trust domains; allowing each trust domain to define its own security policy rules; and providing a central body to enforce the security policy rules of each trust domain within the community.
- a trust broker entity may be provided for creating the community and to act as said central body.
- a method of trust management and security policy enforcement wherein a central body cross certifies with each of a plurality of trust domains to form a trust community and that central body or a different central body enforces security policy rules defined by the trust domains.
- a common central body which may be termed a trust broker and which performs the certifying and enforcing functions.
- a central body acts as trust anchor or central hub of trust relationships in order to establish a trust community in which boundaries can be defined and over which control can be exercised.
- a system comprising a trust broker which operates as a trust anchor or acts as a central hub of a plurality of trust domains and as a security policy enforcement entity for enforcing the security rules of each trust domain.
- a trust and security management system comprising a trust broker which is arranged to act both as a bridge certification authority between a plurality of trust domains and as a security policy enforcement entity for enforcing the security policy rules of each trust domain.
- a method for facilitating interactions via communications networks between computer systems of entities comprising the steps of: creating a trust community which encompasses the trust domains; allowing each trust domain to define its own security policy rules; and providing a central body to enforce the security policy rules of each trust domain within the community.
- a method for facilitating interactions between entities which belong to respective, different trust domains by virtue of having a digital certificate anchored within the respective domain comprising the steps of: creating a trust community which encompasses the trust domains; allowing each trust domain to define its own security policy rules; and providing a central body to enforce the security policy rules of each trust domain within the community.
- apparatus for administering trust management and security policy enforcement comprising: means for cross certifying with each of a plurality of trust domains to create a trust community encompassing said plurality of domains; means for receiving information concerning the security policy within each trust domain; means for receiving, from entities within the community, requests for a decision on the allowability of an activity; means for making decisions on allowability based on received information concerning security policy; and means for outputting decisions to requesting entities.
- apparatus for administering trust management and security policy enforcement comprising: a module for cross certifying with each of a plurality of trust domains to create a trust community encompassing said plurality of domains; a module for receiving information concerning the security policy within each trust domain; a module for receiving, from entities within the community, requests for a decision on the allowability of an activity; a module for making decisions on allowability based on received information concerning security policy; and a module for outputting decisions to requesting entities.
- apparatus for administering trust management and security policy enforcement comprising: a bridge certification authority module for cross certifying with each of a plurality of trust domains to create a trust community encompassing said plurality of domains; and a trust engine and policy agent module for: a) receiving information concerning the security policy within each trust domain; b) receiving, from entities within the community, requests for a decision on the allowability of an activity; c) making decisions on allowability based on received information concerning security policy; and d) outputting decisions to requesting entities.
- the information concerning security policy may be delivered to the appropriate means/module and/or may be actively sought.
- the information may include security policy rules.
- the information may include data needed for use in conjunction with the rules.
- the apparatus will typically be implemented on a plurality of computer systems. Typically, the computer systems will be interconnected via computer/communications networks.
- the modules will typically comprise hardware and software elements. There is essentially little or no limit on the geographical location of the various modules of the apparatus, further any module may in fact be distributed across a plurality of locations.
- the apparatus may be termed as a trust broker apparatus.
- a method of administering trust management and security policy enforcement comprising the step of providing a trust broker entity for: cross certifying with each of a plurality of trust domains to create a trust community encompassing said plurality of the domains; receiving information concerning the security policy within each trust domain; receiving, from entities within the community, requests for a decision on the allowability of an activity; making decisions on allowability based on received information concerning security policy; and outputting decisions to requesting entities.
- the central body/trust broker/apparatus plays what might be considered a passive rather than an active role.
- the central body/trust broker/apparatus implements or enforces rules defined by individual domains and does not define, control or update those rules. This is not to say that a base level of rules (say for determining whether an entity or trust domain can enter the community) cannot be defined by the central body/trust broker/apparatus but rather that the central body /trust broker/apparatus need not define, control or update all of the rules which are applicable to the community. Only implementation/enforcement of those rules is required.
- the principles of the invention may be implemented using one of a plurality of trust mechanisms as the method by which the trust domains' security and policy rules are enforced. Implementation of these methods may be enacted uniquely or collectively to form in combination a full implementation of trust broker enforcing systems.
- the methods may be methods of public key infrastructure trust management and security policy enforcement and the apparatus may be public key infrastructure trust management and security policy enforcement apparatus.
- a computer program, or set of computer programs comprising code portions which when loaded and run on computer means cause the computer means to execute the steps defined in any one of the methods defined above.
- a computer program, or set of computer programs comprising code portions which when loaded and run on computer means cause the computer means to constitute any one of the apparatus defined above.
- the computer means may comprise a plurality of individual computers which may be in different locations.
- the computer program or set of programs may be embodied on one or more data carriers.
- the or each data carrier might be a signal, or a record medium such as a disk.
- Figure 1 shows a schematic architecture of a centralised trust broker system
- Figure la shows more detail of a trust engine of the system shown in Figure 1;
- Figure 2 shows a schematic architecture for a less centralised trust broker system
- Figures 3A to 3E show a flow chart illustrating a typical trust broker process
- FIGS 4 to 11 schematically illustrate another typical trust broker process in more detail.
- This application generally relates to new concepts in the fields of electronic security trust etc., and to the implementation of the concepts. It is considered that once the concepts are explained, their detailed implementation is a straightforward matter for appropriately skilled people in these fields. Further, there are many possible ways in which the concepts may be implemented when looking at implementations at a detailed level and therefore description of detailed implementations are omitted.
- trust is used to mean the well known concept within the field of secure interactions between computers (in their broadest sense; or the entities on behalf of which the computers are operating). To this extent trust is a technical manifestation of traditional trust relationships.
- a trust broker is used to link a plurality of otherwise distinct trust domains to form a trust community (an enlarged trust domain). This gives the possibility of interaction between entities in different trust domains.
- the trust broker also enforces/implements rules within the community on behalf of each and every trust domain.
- a first set of rules are super rules or community rules which govern the behaviour of, and interactions within, the trust community as a whole.
- a second class of rules are entity rules which are specific to each entity which belongs to the trust community.
- entity rules which apply to all members of a particular trust domain within the community but do not apply to entities which are not in that domain
- entity rules and community rules there are different sub-sets of rules characterised by the aspects of e-security to which the rules relate. Therefore, there can be both entity rules and community rules which are security policy rules and trust rules, and moreover, the community security policy rules may include security policy management rules and the community trust rules may include trust management rules.
- Trust management rules and security policy management rules are rules which control the types of or boundaries on rules that may be chosen and set up by entities in the community.
- Community trust and community security policy rules are normal types of rules which could be set by entities and are used in decision making but which apply to the whole community.
- a trust management rule might be "Members may not set Trust policies that do not accommodate reciprocal trust arrangements, i.e. you do not trust him but he has to trust you.”
- a community trust rule might be "Members may trust each other only for transactions of value between £100 and £1000 and may not refuse to trust other members totally.”
- an entity trust rule may be "Member A sets a rule to indicate that entities in Member B's domain may execute trade up to a limit of £1000.”
- a security policy management rule might be "Security policy rules for access to resources must ensure minimum authentication requirements are presented and enforced, i.e. Low Water Mark.”
- a community security policy rule might be "A member must provide identifiable credential information for any entity requesting policy moderation by the Trust Broker even if the entity is in a trusted domain.”
- an entity security policy rule might be "Member A sets a rule that indicates that entities in Member B's domain may access data from its database for use in systems controlled by Member A.”
- the trust broker (or entity which administers the trust broker) does not define the entity rules even though the trust broker does enforce the rules.
- the defining of entity rules is left within the control of each and every trust domain and in principle in the control of each and every entity. However, there may be various levels of control imposed upon the rules that can be defined by the entities. These controls in general will emanate from the trust broker but might also emanate from a particular domain in respect of entities which are members of that domain.
- the trust broker stores or accesses the necessary rules and associated information and uses these to perform its enforcement function.
- This general idea allows each trust domain to have its own set of rules concerning what individual entities are permitted to do and indeed allows each entity to have its own rules without the associated problems encountered in existing systems.
- a relying party in the community is able to prescribe the trust rules it requires to be enforced on its behalf by the trust broker.
- a relying party is an entity within the trust community which makes use of and relies on the trust relevant information and trust status of another entity in the community.
- the trust broker system allows great flexibility and control for trust domains and individual entities within trust domains without imposing a huge administrative burden on any single entity, domain etc.
- the trust broker can be thought of as being an entity that enables and administers a trust broker implementation for a trust community. Moreover, the trust broker manages and controls the policy for broker operations, is trusted in implementing the policy, business and technical components to support trust brokering but is not a trusted third party and does not prescribe trust relationships.
- FIG 1 schematically shows a centralised trust broker system.
- those components which make up the trust broker can be considered to be those which sit within the circle shown in Figure 1.
- elements are described as being part of the trust broker, this does not necessarily mean that they are all situated in one central location but rather suggests that the elements are all under the control of the trust broker and are performing tasks associated with the trust broker process.
- the trust broker system will typically be implemented on a number of computer systems running appropriate software and these computer systems, as alluded to above, may be located in one central location or may be dispersed across different locations as is most convenient. In some instances a single functional module or part of the trust broker implementation may be distributed across several different computer systems.
- the trust broker comprises a bridge (or hub) certification authority (bridge CA) module 1.
- the function of this module 1 is to unify the two trust domains TDl, TD2 so as to form a trust community within which transactions may take place. It will be understood that this unifying process does not merge the domains indistinguishably into one another but gives a trust path to allow the remainder of the trust broker process to take place.
- the trust engine 2 which as a whole is responsible for the control of electronic transactions within the trust community formed by the bridge CA 1.
- a policy agent module 3 is provided and acts in general terms as an interface between the trust engine 2 and the computer systems of entities within the trust community, i.e. in this case, the computer systems of company A and company B.
- the trust engine 2 has access to various sources of information for use in performing its role. These data sources include an access control list 4, an X500 database 5 (X500 being a directory standard which is used in the e-security industry) and external data sources 6 which are accessible via a meta data module 7. These data sources will include information which is needed when making decisions as to whether a particular transaction will proceed. The precise nature of the data which is required will depend on the type of transactions which are taking place. However, in this particular embodiment these pieces of data will not include the rules themselves which will be used for making decisions as these are stored elsewhere.
- the trust engine 2 comprises a decision engine 21 and decision manager 22 as sub-components. It is the decision engine 21 which stores the rules mentioned above.
- the bridge certification module 1 has a function of acting as a trust bridge between the different trust domains. It should be noted that the use of a bridge certification authority is only one possible form of trust bridge that might be used. This is an appropriate form of trust bridge where the trust community operates using digital certificates. However, in implementations where digital certificates are not used, and other credentials (eg user name/password) are used in their place, the trust bridge will take another form but will carry out a similar role in ensuring that there is a trust path between the domains unified by the trust broker. As part of its role, the bridge CA module 1 performs a certificate discovery operation which includes checking that certificates are valid and meet the requirements for use within the trust community.
- a certificate discovery operation includes checking that certificates are valid and meet the requirements for use within the trust community.
- the rules stored in the decision engine 21 will include both community rules and entity rules.
- the decision manager 22 is provided to collect up-to-date information in relation to entity rules and forward these to the decision engine 21 so that the database of rules is kept current.
- the decision manager 22 may function by actively seeking out new or amended entity rules at appropriate times.
- the entity defining the rules will have direct access to the decision manager such that as an entity defines a new rule or amends an existing rule this is reflected in the decision manager 22 immediately.
- the decision manager 22 is located centrally on a trust broker computer but in some implementations the decision manager 22 may have a dispersed nature such that there is a part of the decision manager or a distinct decision manager located at computer systems of some or all of the entities which are members of the trust broker community.
- the trust engine 2 itself has functions beyond those of the decision engine 21 and decision manager 22.
- the trust engine 2 receives requests for decisions concerning transactions from members of the trust community via the policy agent 3 and collects information concerning the context of these requests.
- the trust engine 2 then provides a contextualised request for decision to the decision engine 21 so that a decision can be made using the stored rules.
- the splitting of the decision making task into one where the trust engine 2 first builds a context for the request and then passes a contextualised request for a decision to the decision engine 21 is important because of the complex factors which need to be considered when making a decision. In this particular instance the role of the trust engine 2 can be thought of as finding the necessary facts to ask the right question and provide the raw materials for working out an answer.
- the decision engine 21 itself uses the rules and the raw material to answer the appropriate question or questions.
- the policy agent 3 acts as an interface between the trust engine 2 and the computer systems of company A and company B. Furthermore, in some instances policy agent modules may exist between the data sources 4, 5, 6 and 7 and the trust engine 2. In performing its interface role the policy agent 3 is important in not only allowing communication to take place but also providing a messaging system which is secure and robust. This is to ensure that there is no significant danger of the data which is being passed between the various entities being accessed, tampered with or corrupted without this at least being detected by the system.
- policy agent 3 is shown to be located centrally, this is not necessary. Policy agent modules may be located wherever it is most appropriate or convenient, but wherever the policy agent 3 is located it must in general terms remain under the control of the trust broker.
- FIG. 2 schematically shows a different possible implementation of a trust broker system.
- the system is rather less centralised in that policy agent modules 3 are provided at the sites of company A and company B as are parts of the trust engine 2 in the form of parts of the decision engine 21.
- the local parts of the decision engine 21 provided at the sites of company A and B may contain a sub-set of rules which are particularly appropriate for use in transactions by the respective company and in some instances this may lead to faster processing of requests relating to the allowability of transactions.
- FIGS 3A to 3E show a flow chart for a typical trust broker process which may be carried out using a trust broker system of a type similar to that described above.
- the general context for this process is that a user who has a digital certificate issued by a member of a trust domain which itself is part of a trust community wishes to perform a particular transaction which is managed by an application program with which the user can interact.
- step ST1 the user presents a digital certificate to the application by virtue of attempting to initiate the transaction which he wishes to carry out.
- step ST2 the application checks the validity of the certificate.
- step ST3 one of two things can happen as the result of this check. Either the application sees a trust path for the user which is sufficient for the transaction to be carried out, in which case the process is at an end (step ST4) and the trust broker is not required, or no trust path can be seen. In this second case we move onto step ST5 where the certificate and transaction details are sent to the trust broker by the application. As part of this process, at step ST6, necessary information is coded into a secure messaging transport system and forwarded on to the policy agent located at the trust broker, step ST7.
- step ST8 the policy agent at the trust broker uses the trust engine to start a certificate checking process typically known as certificate discovery. As a first part of this process a check is made that there is a full certificate path. If a full certificate path is not found the trust broker rejects the request at step ST9. If, on the other hand, a full certificate path is found we move to step ST10 where the policy agent uses the trust engine to check the status of the certificates.
- a certificate checking process typically known as certificate discovery.
- step ST11 This results in the trust engine checking whether all of the certificates in the chain are valid at step ST11. If this is not the case the trust broker rejects the request at step ST12. On the other hand, if all the certificates in the chain do validate, the process moves on to step ST 13 where the policy agent, again making use of the trust engine, checks whether the decision making requirements have been met in the message. This results in a check being made that all the applicable data is available at step ST14. If some data is missing then at step ST 15 an error status is entered and a search for additional data is commenced.
- the policy agent and trust engine deliver the information including the appropriate request for a decision to the decision engine at step ST16.
- the decision engine makes the appropriate decision on the request being made making use of the information provided by the policy agent, the rules stored in the decision engine and contextual information gathered and processed by the trust engine.
- a yes or no decision on the transaction is made. If the decision is no then at step ST18 the trust broker rejects the request.
- the rules used in the decision making process will include any pertinent community trust and community security policy rules as well as pertinent entity rules associated with both parties involved. Thus the transaction will be stopped if it would breach any rule in this set of rules.
- step ST19 the result of the trust brokering process is supplied back to the application.
- the decision returned in essence will either be a yes decision (meaning that everything is in order and the transaction can proceed) or a no decision if the trust broker has rejected the request at any of steps ST9, ST12 or ST18.
- the application may act on the response as appropriate, carrying on and completing the transaction where there has been a yes decision.
- FIGS 4 to 11 schematically show a similar process to that described in relation to Figures 3A to 3E. However, this relates to a different scenario and more detail is shown concerning the roles which the different elements or modules of the trust broker system take.
- the particular transaction which is being considered is an attempt by a user, who is a member of one trust domain within the trust community, to make use of an application which is located in a different trust domain within the trust community.
- the trust brokering process as described below is used to determine whether the use of the application is allowed in the particular set of circumstances which relate to the particular request being made. These circumstances need not be limited to just the identity of the user and the application but may be influenced by a vast number of other factors such as the time of day, whether the application has sufficient resources to accommodate the user at present, whether the task which the user wishes to perform is an accepted task, etc. This process, however, is transparent to the user.
- the user tries to access the desired application.
- his computer system presents his credential, for example a digital certificate.
- his credential for example a digital certificate.
- the request is accepted and received by a policy agent which gathers relevant data, formats the request, establishes its context and delivers this information via a secure messaging system to the trust broker as illustrated in Figure 5.
- the trust broker receives this request and carries out validation status and authentication tasks, in this instance acting as a bridge certification authority and using a certificate discovery process.
- the certificate status information is gained from an external data source and used by the bridge certification authority of the trust broker.
- a request for a decision is passed to the trust engine.
- the trust engine establishes the context of the request and collects relevant information as illustrated in Figure 7. At least some of the data which is required in this case is again from an external resource.
- the trust engine passes a contextualised request to the decision engine as illustrated in Figure 8.
- the decision engine applies the rules of the trust community as a whole and the rules of the entities involved to determine whether the transaction can proceed.
- the entity rules stored at the decision engine are supplied via the decision manager which either collects or receives these rules from the relevant entities.
- the decision engine outputs a decision to the policy agent having applied the appropriate rules. Assuming that the decision is positive the requested access can proceed.
- the decision which has been made is a context sensitive trust result such that the approval given is based on the entire context. It should be noted that a very similar request made by the same user might be refused in future if some aspect of the context means that a different decision has to be made. For example, the user might be allowed access to the application concerned only at certain times during the day or week. In the case shown in Figure 11 it is assumed that the decision is positive and therefore access to the application is approved. Whilst the majority of the above description has been given in conceptual terms it will be appreciated that apparatus may be provided for carrying out the functions and processes described and more particularly in many implementations the apparatus will take the form of one or more computer systems operating under the control of appropriate software.
- this software may exist on appropriate computer readable data carriers such as electronic signals or data storage means such as floppy disks, hard disks or CD roms.
- appropriate computer readable data carriers such as electronic signals or data storage means such as floppy disks, hard disks or CD roms.
- data storage means such as floppy disks, hard disks or CD roms.
- there may be a plurality of different computer systems which may or may not be located in different locations and each of these may run a respective part of the software used to implement the system as a whole.
- the trust broker system tackles the problem of interoperability and interaction between organisations that wish to enable trust relationships electronically, typically as part of normal business operations. It comprises a model which combines PKI trust management (or other types of trust domain management) via a trust bridge and security policy enforcement (access, authorisation and privilege) to give a mechanism which fully defines the trust and privileges for a given activity.
- the trust broker on behalf of the community uses procedural and technical means to manage and enforce the policies that define the boundaries of operation within the community.
- the trust broker builds on accepted models and standard mechanisms for defining and publishing policy.
- the trust broker provides, via the rule bases that comprise the decision manager, the framework and tools to establish relationships with other community members as it sees fit.
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP02743442A EP1407593A2 (en) | 2001-07-17 | 2002-07-16 | Trust management |
AU2002345230A AU2002345230A1 (en) | 2001-07-17 | 2002-07-16 | Trust management |
US10/484,158 US20040187031A1 (en) | 2001-07-17 | 2002-07-16 | Trust management |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GBGB0117429.1A GB0117429D0 (en) | 2001-07-17 | 2001-07-17 | Trust management |
GB0117429.1 | 2001-07-17 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2003009512A2 true WO2003009512A2 (en) | 2003-01-30 |
WO2003009512A3 WO2003009512A3 (en) | 2003-05-08 |
Family
ID=9918675
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/GB2002/003258 WO2003009512A2 (en) | 2001-07-17 | 2002-07-16 | Trust management |
Country Status (5)
Country | Link |
---|---|
US (1) | US20040187031A1 (en) |
EP (1) | EP1407593A2 (en) |
AU (1) | AU2002345230A1 (en) |
GB (1) | GB0117429D0 (en) |
WO (1) | WO2003009512A2 (en) |
Families Citing this family (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1203332A4 (en) | 1999-02-12 | 2002-09-25 | Mack Hicks | System and method for providing certification-related and other services |
US20020029200A1 (en) | 1999-09-10 | 2002-03-07 | Charles Dulin | System and method for providing certificate validation and other services |
WO2001024082A1 (en) | 1999-09-24 | 2001-04-05 | Mary Mckenney | System and method for providing payment services in electronic commerce |
WO2002021408A1 (en) | 2000-09-08 | 2002-03-14 | Tallent Guy S | System and method for transparently providing certificate validation and other services within an electronic transaction |
US7072870B2 (en) | 2000-09-08 | 2006-07-04 | Identrus, Llc | System and method for providing authorization and other services |
US7318238B2 (en) * | 2002-01-14 | 2008-01-08 | Microsoft Corporation | Security settings for markup language elements |
US8015301B2 (en) * | 2003-09-30 | 2011-09-06 | Novell, Inc. | Policy and attribute based access to a resource |
US7299493B1 (en) * | 2003-09-30 | 2007-11-20 | Novell, Inc. | Techniques for dynamically establishing and managing authentication and trust relationships |
US7316027B2 (en) * | 2004-02-03 | 2008-01-01 | Novell, Inc. | Techniques for dynamically establishing and managing trust relationships |
US7467415B2 (en) * | 2003-09-30 | 2008-12-16 | Novell, Inc. | Distributed dynamic security for document collaboration |
US7581097B2 (en) * | 2003-12-23 | 2009-08-25 | Lenovo Pte Ltd | Apparatus, system, and method for secure communications from a human interface device |
US7647256B2 (en) * | 2004-01-29 | 2010-01-12 | Novell, Inc. | Techniques for establishing and managing a distributed credential store |
US8078740B2 (en) | 2005-06-03 | 2011-12-13 | Microsoft Corporation | Running internet applications with low rights |
US7774827B2 (en) * | 2005-06-06 | 2010-08-10 | Novell, Inc. | Techniques for providing role-based security with instance-level granularity |
US9418040B2 (en) | 2005-07-07 | 2016-08-16 | Sciencelogic, Inc. | Dynamically deployable self configuring distributed network management system |
US8261331B2 (en) * | 2006-01-17 | 2012-09-04 | International Business Machines Corporation | Security management for an integrated console for applications associated with multiple user registries |
US8185737B2 (en) | 2006-06-23 | 2012-05-22 | Microsoft Corporation | Communication across domains |
CN101207613B (en) * | 2006-12-21 | 2012-01-04 | 松下电器产业株式会社 | Method, system and apparatus for authentication of striding network area information communication |
US10019570B2 (en) | 2007-06-14 | 2018-07-10 | Microsoft Technology Licensing, Llc | Protection and communication abstractions for web browsers |
US8255975B2 (en) * | 2007-09-05 | 2012-08-28 | Intel Corporation | Method and apparatus for a community-based trust |
US8250639B2 (en) | 2007-11-20 | 2012-08-21 | Intel Corporation | Micro and macro trust in a decentralized environment |
AU2009205675B2 (en) * | 2008-01-18 | 2014-09-25 | Identrust, Inc. | Binding a digital certificate to multiple trust domains |
CN102150408B (en) * | 2008-09-12 | 2014-11-26 | 诺基亚通信公司 | Methods, apparatuses and computer program product for obtaining user credentials for an application from an identity management system |
US8364970B2 (en) * | 2009-02-18 | 2013-01-29 | Nokia Corporation | Method and apparatus for providing enhanced service authorization |
US8752152B2 (en) * | 2009-12-14 | 2014-06-10 | Microsoft Corporation | Federated authentication for mailbox replication |
US20120180120A1 (en) * | 2011-01-12 | 2012-07-12 | Sonit Basantkumar Jain | System for data leak prevention from networks using context sensitive firewall |
US9054971B2 (en) * | 2012-04-24 | 2015-06-09 | International Business Machines Corporation | Policy management of multiple security domains |
US9282120B2 (en) | 2013-02-01 | 2016-03-08 | Vidder, Inc. | Securing communication over a network using client integrity verification |
US10181036B2 (en) * | 2015-06-24 | 2019-01-15 | Lenovo Enterprise Solutions (Singapore) Pte. Ltd. | Automatic discovery and installation of secure boot certificates |
US10469262B1 (en) | 2016-01-27 | 2019-11-05 | Verizon Patent ad Licensing Inc. | Methods and systems for network security using a cryptographic firewall |
WO2017173145A1 (en) * | 2016-03-30 | 2017-10-05 | The Privacy Factor, LLC | Systems and methods for analyzing, assessing and controlling trust and authentication in applications and devices |
US10554480B2 (en) | 2017-05-11 | 2020-02-04 | Verizon Patent And Licensing Inc. | Systems and methods for maintaining communication links |
US11201937B2 (en) * | 2018-11-22 | 2021-12-14 | Jeffrey Alan Carley | Message broker customization with user administered policy functions |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0465016A2 (en) * | 1990-06-25 | 1992-01-08 | Digital Equipment Corporation | Distributed multilevel computer security system and method |
WO1997037477A2 (en) * | 1996-03-29 | 1997-10-09 | Cabletron Systems, Inc. | Policy management and conflict resolution in computer networks |
EP0942349A2 (en) * | 1998-03-12 | 1999-09-15 | Hewlett-Packard Company | Cryptographic apparatus for an international cryptography framework |
WO2000069145A1 (en) * | 1999-05-06 | 2000-11-16 | Watchguard Technologies, Inc. | Generalized network security policy templates for implementing similar network security policies across multiple networks |
WO2000069120A1 (en) * | 1999-05-06 | 2000-11-16 | Watchguard Technologies, Inc. | Managing multiple network security devices from a manager device |
US6202157B1 (en) * | 1997-12-08 | 2001-03-13 | Entrust Technologies Limited | Computer network security system and method having unilateral enforceable security policy provision |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6067620A (en) * | 1996-07-30 | 2000-05-23 | Holden; James M. | Stand alone security device for computer networks |
US5958015A (en) * | 1996-10-29 | 1999-09-28 | Abirnet Ltd. | Network session wall passively listening to communication session, with use of access rules, stops further communication between network devices by emulating messages to the devices |
US6865674B1 (en) * | 1999-06-02 | 2005-03-08 | Entrust Technologies Limited | Dynamic trust anchor system and method |
-
2001
- 2001-07-17 GB GBGB0117429.1A patent/GB0117429D0/en not_active Ceased
-
2002
- 2002-07-16 AU AU2002345230A patent/AU2002345230A1/en not_active Abandoned
- 2002-07-16 US US10/484,158 patent/US20040187031A1/en not_active Abandoned
- 2002-07-16 WO PCT/GB2002/003258 patent/WO2003009512A2/en not_active Application Discontinuation
- 2002-07-16 EP EP02743442A patent/EP1407593A2/en not_active Withdrawn
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0465016A2 (en) * | 1990-06-25 | 1992-01-08 | Digital Equipment Corporation | Distributed multilevel computer security system and method |
US5889953A (en) * | 1995-05-25 | 1999-03-30 | Cabletron Systems, Inc. | Policy management and conflict resolution in computer networks |
WO1997037477A2 (en) * | 1996-03-29 | 1997-10-09 | Cabletron Systems, Inc. | Policy management and conflict resolution in computer networks |
US6202157B1 (en) * | 1997-12-08 | 2001-03-13 | Entrust Technologies Limited | Computer network security system and method having unilateral enforceable security policy provision |
EP0942349A2 (en) * | 1998-03-12 | 1999-09-15 | Hewlett-Packard Company | Cryptographic apparatus for an international cryptography framework |
WO2000069145A1 (en) * | 1999-05-06 | 2000-11-16 | Watchguard Technologies, Inc. | Generalized network security policy templates for implementing similar network security policies across multiple networks |
WO2000069120A1 (en) * | 1999-05-06 | 2000-11-16 | Watchguard Technologies, Inc. | Managing multiple network security devices from a manager device |
Also Published As
Publication number | Publication date |
---|---|
WO2003009512A3 (en) | 2003-05-08 |
US20040187031A1 (en) | 2004-09-23 |
EP1407593A2 (en) | 2004-04-14 |
GB0117429D0 (en) | 2001-09-12 |
AU2002345230A1 (en) | 2003-03-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20040187031A1 (en) | Trust management | |
Schlatt et al. | Designing a framework for digital KYC processes built on blockchain-based self-sovereign identity | |
Tobin et al. | The inevitable rise of self-sovereign identity | |
US20030229812A1 (en) | Authorization mechanism | |
US20020169876A1 (en) | Method and system for third party resource provisioning management | |
US20100306824A1 (en) | Trust and identity in secure calendar sharing collaboration | |
Luong et al. | An approach for project management system based on blockchain | |
Aviv et al. | Reference Architecture for Blockchain-Native Distributed Information System | |
Upadhyaya et al. | Revolutionizing healthcare systems of a developing country using blockchain | |
Pham et al. | On a taxonomy of delegation | |
Yao | Trust management for widely distributed systems | |
Zaidi et al. | Fabrication of Flexible Role-Based Access Control based on Blockchain for Internet of Things Use Cases | |
Cameron et al. | Introduction to IAM Architecture (v2) | |
El Haddouti et al. | Fedidchain: An innovative blockchain-enabled framework for cross-border interoperability and trust management in identity federation systems | |
WO2002067173A9 (en) | A hierarchy model | |
Baldwin et al. | Trust services: a framework for service-based solutions | |
Liu et al. | A pattern-oriented reference architecture for governance-driven blockchain systems | |
Baldwin et al. | A model-based approach to trust, security and assurance | |
Gusarovs et al. | An Intermediate Model for Code Generation from the Two-Hemisphere Model | |
Liu et al. | BGRA: A reference architecture for blockchain governance | |
Alagar et al. | Uniform Service Description and Contextual Access Control for Trustworthy Cloud Computing | |
Prabu et al. | Academic Information Storage and Verification Using Blockchain Technologies | |
Buecker et al. | Federated Identity Management and Web Services Security | |
Damon | A framework for identity and access assurance | |
AU2002245006B2 (en) | A hierarchy model |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC 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 MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ 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) | ||
WWE | Wipo information: entry into national phase |
Ref document number: 10484158 Country of ref document: US |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2002743442 Country of ref document: EP |
|
WWP | Wipo information: published in national office |
Ref document number: 2002743442 Country of ref document: EP |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
WWW | Wipo information: withdrawn in national office |
Ref document number: 2002743442 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: JP |
|
WWW | Wipo information: withdrawn in national office |
Country of ref document: JP |