FastFed Working Group - Charter
1) Working Group name
Fast Federation (FastFed)
The purpose of this Working Group is to develop a meta-data document specification, APIs, and workflow to enable an administrator to federate an identity provider and a hosted application that supports one or more of OpenID Connect, SAML, and SCIM and enable configuration changes to be communicated between the identity provider and hosted application.
The Working Group will define:
- Meta-data documents for the identity provider and hosted application
- APIs for the identity provider and hosted application to communicate
with each other
- A recommended workflow for the administrator
- A mechanism for the identity provider and the application to
communicate configuration changes
Out of scope:
- Generic federation between identity systems
- Application configuration mechanisms
Any items not expressly mentioned as being in scope or out of scope are to
be determined by the Working Group.
4) Proposed specifications
The Working Group proposed to create one or more documents that specify the meta-data to be provided by the identity provider and hosted application, APIs for configuration communication between the identity provider and hosted application and mechanism for the identity provider and hosted application to communicate configuration changes. The document(s) will also contain non-normative content to assist implementers in developing and deploying the specified functionality.
5) Anticipated audience or users
- Identity Providers
- Hosted application developers
- Administrators looking to simplify federation of hosted applications
Work will be conducted in English.
7) Method of work
E-mail discussions on the working group mailing list, regular working group conference calls, and opportunistic face-to-face meetings when a significant number of active members are collocated.
8) Basis for determining when the work is completed
Rough consensus and running code. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope and there are at least two identity providers that each work with at least two hosted applications.
- SAML 2.0
- OpenID Connect
- SCIM 2.0 [RFC 7644]
- OpenID Connect Federation proposal submitted to the OpenID Connect working group
- Dick Hardt, AWS (editor)
- Michael B. Jones, Microsoft
- John Bradley, Ping Identity
- Chuck Mortimore, Salesforce
- Phil Hunt, Oracle
In many cases, Fintech services such as aggregation services uses screen scraping and stores user passwords. This model is both brittle and insecure. To cope with the brittleness, it should utilize an API model with structured data and to cope with insecurity, it should utilize a token model such as OAuth [RFC6749, RFC6750].
There are some examples of API models such as OFX, but it uses SOAP/XML model. However, SOAP/XML model has grown unpopular among the developers. Also, the OFX does not deploy the token model but uses user password, causing insecurity.
This working group aims to rectify the situation by developing a REST/JSON model protected by OAuth.
IdP and hosted app have prepared and hosted meta-data files exposing
1) Admin authenticates to IdP in browser
2) Admin selects hosted app to federate with from list at IdP (which
had previously been configured) or enters URL of hosted app configuration
3) IdP optionally presents config options
4) IdP redirects Admin to hosted app
5) Admin authenticates to hosted app or creates new account
6) Hosted app optionally gathers config options
7) Hosted app redirects admin to IdP
8) IdP confirms successful federation => OIDC, SAML, and/or SCIM are
now configured and working between IdP and hosted app
Changes to IdP or hosted application configuration are made and appropriate
actions are taken by the other party.
This Working Group will target producing use cases and requirements within 2 months of inception in order to guide its design effort, and will target 6-12 months overall to develop a V1.0 set of profiles and other auxiliary materials, facilitating the development of multiple independent draft implementations during this time. The following are suggested initial milestones for consideration by the Working Group:
- November 2015: Approval of Working Group creation.
- June 2016 Approve Implementer’s drafts (within 12 months after formal kickoff of WG).
- Interop testing among multiple implementations (once Implementer’s Drafts are available).
- December 2016 Approve Final profiles (6-12 months after Implementer’s Drafts)