Child policies may be modified/created by, or have parameters specified by, application service providers including application developers therefor. That is, according to the embodiments and techniques for the IEF described herein, another entity, e.g., associated with the identity policy host, associated with an identity operator, etc., may create or modify child policies for utilization by applications.
By using trustframeworks to conceptualize and capture the requirements of a “community of interest” and then define these requirements in a policy document, policy authors (e.g., identity operators) can build identity workloads of varying complexity, in a manner that aligns with the needs or requirements of the drivers of the community and not the technology. Having a language for articulating the identity needs for workloads fosters collaboration and partnerships between policy authors, identity experts, and business stakeholders.
A trustframework engine is the service that executes the trustframework policy. The trustframework engine may comprise loosely coupled state machine handlers that can invoke specific concrete implementations of identity semantics, and a state machine that instantiates and executes the identity semantics in the context of the user journey and the policy being executed. Each authorization request made to the IEF may be processed in the context of a trustframework policy that defines the user journey. In embodiments, there may be no identity logic outside of what is declared in the policy and implemented by the specific claims providers. This is analogous to the trustframework policy being the identity application and the trustframework engine being an operating system that runs that application, except in this case, the instruction set allowed by the operating system comprises the constructs exposed by the trustframework schema.