FastFed Charter



OpenID Foundation Fast Federation Working Group Charter

1) Working Group name:

Fast Federation (FastFed)

2) Purpose

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.

3) Scope

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 Deliverables

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

6) Language

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.

Background information

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.

Related work:

  • SAML 2.0
  • OpenID Connect
  • SCIM 2.0 [RFC 7644]
  • OpenID Connect Federation proposal submitted to the OpenID Connect working group -https://github.com/rohe/pyoidc/blob/master/oidc_fed/oidcfed.txt

Proposers

  • Dick Hardt, AWS (editor)Michael B. Jones, MicrosoftJohn Bradley, Ping Identity

    Chuck Mortimore, Salesforce

    Phil Hunt, Oracle

Anticipated contributions:

*Expected Workflow*

Pre workflow

IdP and hosted app have prepared and hosted meta-data files exposing
configuration APIs

Administrator workflow

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

Post Workflow

Changes to IdP or hosted application configuration are made and appropriate
actions are taken by the other party.