• Reduce operation and development costs by reducing complexity.
  • Improve interoperability by developing authentication and attribute systems that can be used in more scenarios.
  • Improve security by divulging confidential information only as required.
  • Improving data quality by evidenced information.
  • Common over Custom: where possible design for a system
  • Automation over Operation: where possible, develop towards a User experience flow that does not require asking about Context, or other scenarios that require user input.
  • On B2C:
  • B2C's business model is bridging to general IdPs, not solve edge Education cases, and therefore will not add flows to manage Context choice.
  • IdPs outside of our control will not add flows to provide choice of context.
  • This implies that either Context Flow can only be done using WFIAM, and therefore B2C is superfluous if we are using only one IdP, or Context (School) should be handled as a secondary step, post Authentication.
  • Issuance of Sensitive Claims should be limited beyond those accepted by the End User. This implies that embedding Scholastic/Career identifiers/rank, etc. should therefore not be the default behaviour of B2C. Or it must be encrypted, which has the risk of causing integration propblems with some 3rd party services.
  • The legacy ability of ESAA – repeated in WFIAM – to select Context (and therefore Roles) during Signup should not be the basis of current and future IDA integration using OIDC as it is not what OIDC supports by default.
    • Specialized secondary Resource Services would be the most decoupled approach.

Optional ESL OIDC BrokeringESLCan be WFIAM or externalService to allow for anyIdP. EIther way, actingas just another ResourceServerOIDC BrokerAuthProfileSocialIdPsAuthProfileWFIAMAuthProfileLegacy Context Selector UILegacy UI is accessed duringsignin via SAML to embedClaims. But this legacy stepneed not be continued as aWFIAM service.IDA Metadata ServerContextUX, as requiring inputEOIResource ClientResource Server