The described IEF utilizes trustframework policies (e.g., identity policies) that allow an identity expert to compose an identity system with desired, identity-specific user journeys. Within the IEF, a single trustframework policy may provide a basis for some or all of business-to-consumer functionality, business-to-business functionality, business-to-employee functionality, and/or the like. In this way, different identity protocols are leveraged to provide a seamless, centralized solution. The IEF may include commonly-used verification providers “out of the box” to be invoked via the trustframework policy. For instance, these verification providers may include, but are not limited to, an email address validation provider, an identity provider (IdP) for local accounts, a multi-factor authentication provider, a self-asserted provider, Azure? Active Directory? from Microsoft Corporation of Redmond, Wash. (as a user directory provider), etc. A relying party, e.g., an application or application service provider, calls an identity policy for invocation and subsequent execution of a user authentication process. In embodiments, any identity policy of an included identity provider may be designated or identified as a default policy if no specific policy is specified in a call from an application to the IEF. Accordingly, the relying party chooses the user journey to enforce for the current request, and chooses the list of claims the application requires as part of the token needed to authenticate the user and allow access.