The LIGO Document Control Center (DCC) is the place where all LIGO documents are to be stored and catalogued. Some of the documents are very low risk (some are
even public) and coming in with a federated identity with little assurance (not even Bronze) is fine.
Some of the documents are higher risk and accessing them with a federated identity is going to require a Silver assurance--we need to be sure we understand who is accessing those documents. So we are going to authorize access to those documents not only to the identity, but also require that the identity is being asserted with Silver.
So before the ACL might have been
albert.einstein@LIGO.ORG is in group Communities:LVC:LSC:VIP
but now the ACL will have to be
alberte@uwm.edu is in group Communities:LVC:LSC:VIP AND the IdP is asserting Silver
Still, there are some documents that we consider super sensitive--access by the wrong people could lead to real legal problems costing real money, or major embarrassment to the project or people in the project.
For those documents we are going to require the use of a local, strongly vetted LIGO credential (until such time there is a 'Gold' level of assurance from InCommon that we can embrace). So the ACL will still be
albert.einstein@LIGO.ORG is in group Communities:LVC:LSC:VIP
That means that in order to support federation for this SP and have a good user experience, we need
alberte@uwm.edu and albert.einstein@LIGO.ORG
to be linked and linked well, and to have the authorization work well.
Ideally Dr. Einstein can browse around on a daily basis using alberte@uwm.edu, but when the DCC doesn't want to let him see a document because only albert.einstein@LIGO.ORG can see it, ideally the DCC itself as an application can somehow get enough help from the infrastructure to say "Did you perhaps
want to use your albert.einstein@LIGO.ORG identity instead?" and then when he clicks "yes" the appropriate assertions happen and it all "just works".
In order for that to be seamless and work well there has to be an easy way for an application to "hook into" some infrastructure so that when an authorization is denied it can see if there is a linked profile that would have been given access and then provide a flow that works for the user.
Or maybe the application is just configured that whenever it denies some authorization the flow sends the browser to some service and the service does the hard work?