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

Tue Mar 21 04:00:40 UTC 2017

Thanks for sharing the problem statement and apologize that I could not
join the past meetings.

few suggestions from me about standardization target as well as certificate
rotations, SCIM configuration and so on;
* format for sub claim on id_token as nameid-format of SAML
* definition for key attribute mapping between RP and IdP.(in some case, RP
requires key value on other attribute, not on sub or nameid)

Naohiro

2017-03-21 5:49 GMT+09:00 Phil Hunt via Openid-specs-fastfed <
openid-specs-fastfed at lists.openid.net>:

> 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
> 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 *easier*than 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>
> *Date: *Wednesday, March 15, 2017 at 3:32 PM
> *To: *"McAdams, Darin" <darinm at amazon.com>, "openid-specs-fastfed at lists.
> openid.net" <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@
> lists.openid.net> on behalf of "McAdams, Darin via Openid-specs-fastfed" <
> openid-specs-fastfed at lists.openid.net>
> *Reply-To: *"McAdams, Darin" <darinm at amazon.com>
> *Date: *Sunday, March 5, 2017 at 10:23 AM
> *To: *"openid-specs-fastfed at lists.openid.net" <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
> 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=
>
>
>
> _______________________________________________
> Openid-specs-fastfed mailing list
> Openid-specs-fastfed at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fastfed
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20170321/3f4c0f11/attachment-0001.html>