[Openid-specs-fastfed] FastFed Meeting Notes, March 2 2017

Mon Mar 20 20:49:47 UTC 2017

Darin,

Thanks for this...

I recall a couple of key considerations from Dick and Pam…

* Too many options - a FASTfed profile could include specific sets of configurations that are supported (a reduction in options).  Right now when you combine, OAuth, SAML, OIDC the combinations are endless. FASTfed is not intended to work for every possible scenario - just those who can support  fast fed profile.

* On the justification side - it turns out manual administration on each side takes too much time on a per application basis. I recall Pam had a spreadsheet showing just how much config data options are needed.  I think all of us are finding we’re not administering 10s or 100s but 1000s to 10ks of relationships going forwards.  

In theory, once an app has a client ID (or other credential in the case of SAML), shouldn’t it be possible for it to auto-discover, negotiate, and self-register? 

Phil

Oracle Corporation, Identity Cloud Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com/>phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>

> On Mar 20, 2017, at 9:29 AM, McAdams, Darin via Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net> wrote:
> 
> Thanks for the nudge  : )
> Below is a summary of the problem statement as far as I understand it. If anyone believes it to be wildly off-course or wants to suggest additional angles to consider, send them along!
> -Darin
>  
> -------------------------------------------
> Today, setting up a federation is harder than it should be. Typical instructions are full of Identity terminology that can be off-putting to novice users. Executing the instructions requires an administrator to open multiple browser windows for both the service and identity providers and copy-and-paste values between the two parties. Being human, mistakes inevitably happen; steps are missed, typos occur. As a result, something that could theoretically be accomplished in a few minutes ends up taking days, with the administrator experiencing a frustrating sequence of unexpected failures and confusing error messages.
>  
> As a result of the friction, federation is used less often than it could be. Many service providers are seeing very low adoption rates for federation, with the vast majority of users choosing to create yet-another username/password for the service.
>  
> By making federation easier, we hope three problems can be addressed.
>  
> First, the security implications of passwords are well-understood by the Identity community. By reducing the barriers to federation, it is desired to further reduce the proliferation of passwords and continue making the Internet more secure.
>  
> Second, when enterprise employees create yet-another username/password for SaaS applications used on the job, the shadow IT footprint increases. Enterprises cannot audit activity nor automatically clean up resources when an employee leaves. By making federation easier to configure (or self-service by non-technical employees?), the shadow IT footprint can be reduced.
>  
> Finally, there is pain for IDaaS providers who vend pre-configured catalogues of SaaS applications in order to minimize the federation setup costs. Because of the manual effort and lack of consistency between SaaS application configurations, each catalog entry can become a bespoke implementation. This increases the cost of implementation for IDaaS providers and slows the addition of new apps into the catalog.
>  
> To address these problems, FastFed seeks to minimize the number of manual steps to setup a federation.
>  
> An easy place to begin is the multi-step process in which administrators copy-and-paste configurations between the service and identity providers. Humans are a lossy, error-prone data bus. Rather than relying on humans to copy data, it would be preferable to point the two systems at each other and let the computers consume each other’s information. At its simplest, this could take the form of a 3 line metadata file containing the federation protocol (e.g. SAML, OIDC), a location for the configuration (e.g. SAML Metadata, OIDC Discovery docs), and a location for keys (e.g. SAML certificates).  If the relevant parties hosted this information at a URL, an administrator only needs to give one party’s URL to the other and allow the computers do the remainder of the work.
>  
> Once this communication channel is established, additional opportunities present themselves. While these are less well-defined, the group may also consider the following:
> * Certificate rotations
> * SCIM configurations
> * A catalog to make it easier to discover service and identity providers using plain-language names, rather than URLs.
> * Advertising service capabilities (e.g. what types of resources and actions are provided by the service?).  For example, is there an opportunity to help administrators setup federation via an experience that asks in plain non-technical language: “Here are a bunch of things your users could potentially do... Check boxes for what is allowed.”
>  
> Nothing is free, and this approach will require changes by existing service providers in order to support FastFed. At its simplest, this effort would involve simply hosting another metadata document. In more complex cases, the service provider may need to simplify their onboarding experience and become more consistent in order to become “FastFed Compliant”. If service providers reap benefits by being more easily discoverable and usable in IdP and IDaaS catalogs, it will help motivate these investments. New services, of course, should ideally see value in being FastFed compliant on day one.
>  
> The measurement of success for this standard is not whether federation setup becomes free, but whether it becomes easierthan undesirable alternatives such as password authentication. Through the ecosystem of standards and toolkits, the goal is for federation to become the easiest choice.
>  
>  
>  
> From: Emily Xu <exu at vmware.com <mailto:exu at vmware.com>>
> Date: Wednesday, March 15, 2017 at 3:32 PM
> To: "McAdams, Darin" <darinm at amazon.com <mailto:darinm at amazon.com>>, "openid-specs-fastfed at lists.openid.net <mailto:openid-specs-fastfed at lists.openid.net>" <openid-specs-fastfed at lists.openid.net <mailto:openid-specs-fastfed at lists.openid.net>>
> Subject: Re: [Openid-specs-fastfed] FastFed Meeting Notes, March 2 2017
>  
> Hi Darin,
>  
> When do you think you can share “an overview of the problem statement and use cases”? Sorry for asking since I could not find it from anywhere else.
>  
> Thanks,
> Emily
>  
> From: Openid-specs-fastfed <openid-specs-fastfed-bounces at lists.openid.net <mailto:openid-specs-fastfed-bounces at lists.openid.net>> on behalf of "McAdams, Darin via Openid-specs-fastfed" <openid-specs-fastfed at lists.openid.net <mailto:openid-specs-fastfed at lists.openid.net>>
> Reply-To: "McAdams, Darin" <darinm at amazon.com <mailto:darinm at amazon.com>>
> Date: Sunday, March 5, 2017 at 10:23 AM
> To: "openid-specs-fastfed at lists.openid.net <mailto:openid-specs-fastfed at lists.openid.net>" <openid-specs-fastfed at lists.openid.net <mailto:openid-specs-fastfed at lists.openid.net>>
> Subject: [Openid-specs-fastfed] FastFed Meeting Notes, March 2 2017
>  
> (Apologies if I get anyone’s name wrong. Was copying from the GoToMeeting usernames.)
>  
> Meeting opened with general discussion about next steps.
> ·         What problems are we trying solve?
> ·         Knowing which use cases are in/out would be helpful.
> ·         For newcomers, looking for information on the WG but what was found so far was a presentation (From IIW) and some meeting minutes. Are there more documents? (Dick: there aren’t today)
>  
> Dick proposed writing a draft spec in order to drive the discussion forward. Suggested Darin McAdams to draft the first iteration. Asked for concerns; none raised.
> To confirm alignment, before writing the draft, Darin will share an overview of the problem statement and use cases. If there is contention on the direction, an earlier meeting will be scheduled on demand. If no contention on the use cases, the draft will proceed and be published by April 14 to give time for members to review before next IIW.
>  
> There was preliminary discussion about the scope of the draft.
> ·         Dick – start with metadata and sign on, getting data from idp to rpm, your basic setup. There will be a need for more advanced things around provisioning and stuff like that, but we shouldn’t let that complexity block us from solving the SSO portion upfront. Once we get people along the path, we get continue to more things. But, lots of value in getting started down that path.
> ·         Prateek – Enabling SSO is right and part of it. Let’s definitely get SSO out of the way. Make that a little lighter. Hoping for additional guidance and encouragement on provisioning flows. Not the details, more of a model, pick choice A or choice B. Not opposed to knocking of SSO; we know that is relatively structured. But, a lot of the story at the next layer is “what is the information model that relates identities at both the endpoints and how that gets exchanged to the extend it needs to be exchanged. That’s the part we find quite difficult. What we see happening is that people will pick up a whole bunch of stuff from OIDC, OAuth, slug of SCIM, shove it all together in interesting way, and then bring it to us. Would be awesome if we could point them at a template that would be useful for them.
>  
> Who will be at IIW?
> ·         Emily, Mortrza, Dick, Darin.  (Apologies if I missed anyone)
> _______________________________________________
> Openid-specs-fastfed mailing list
> Openid-specs-fastfed at lists.openid.net <mailto:Openid-specs-fastfed at lists.openid.net>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dfastfed&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=0sb1TrkJ0gH1F6rvcbpryJNcP4uEUfDQ-TGq486NLJ4&s=mXFlmPwPlu0T24pbNfa1ngjdry_7yXxrflpgtI9UWYU&e= <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dfastfed&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=0sb1TrkJ0gH1F6rvcbpryJNcP4uEUfDQ-TGq486NLJ4&s=mXFlmPwPlu0T24pbNfa1ngjdry_7yXxrflpgtI9UWYU&e=> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20170320/3b1cb05f/attachment-0001.html>