[OIDFSC] FastFed WG proposed charter

[Dick Hardt]

I did not see any dissenting votes. Were there any? If not, then the WG is
approved, correct?

Besides setting up the mail list etc., the next step is getting IPR
agreements from participants, correct?

On Thu, Jun 9, 2016 at 11:26 AM, Mike Jones <Michael.Jones at microsoft.com>
wrote:

> I am in favor of approving this charter.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Dick Hardt [mailto:dick.hardt at gmail.com]
> *Sent:* Friday, June 3, 2016 2:20 PM
> *To:* Openid Specs Council <openid-specs-council at lists.openid.net>
> *Cc:* Mike Jones <Michael.Jones at microsoft.com>; John Bradley <
> ve7jtb at ve7jtb.com>; Chuck Mortimore <cmortimore at salesforce.com>; Phil
> Hunt <phil.hunt at oracle.com>; Dick at amazon.com
> *Subject:* FastFed WG proposed charter
>
>
>
> (reposting from personal email as listserv is rejecting email from
> amazon.com)
>
> Please find below the proposed charter to create a new OpenID Foundation
> Working Group, *FastFed*
>
> /Dick
>
>
>
> *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*
>
>
>
> *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, Microsoft
>
> John Bradley, Ping Identity
>
> Chuck Mortimore, Salesforce
>
> Phil Hunt, Oracle
>
>
>
> *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.
>
>
>



-- 
Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about
projects I am working on!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20160620/cee5a4cf/attachment.html>