InC Research Participants

[Scott Koranda <>]

> 
>     On Sep 1, 2016, at 1:23 PM, Cantor, Scott 
> <>
>  wrote:
> 
> 
>          I fear our requirement, from IGTF, to whitelist only eduGAIN IdPs 
> with
>          both the research-and-scholarship and sirtfi tags is sending us 
> down
>         the
>          whitelisting path again, when we should be listing all IdPs and
>         handling
>          the errors. Maybe we should list all the eduGAIN IdPs then show an
>         error
>          page if users select an IdP that doesn't support
>         research-and-scholarship
>          and sirtfi? Maybe that's something we can do when sirtfi is more
>         widely
>          adopted.
> 
> 
>     Maybe related to my question above. I noticed the same disconnect, but 
> it
>     sounds like there's a policy reason you can't let them succeed anyway, 
> so
>     it's more a case of error behavior. I would agree that it seems 
> confusing
>     to hide those IdPs in a way that doesn't clarify to the user what's 
> going
>     on.
> 
>     In that vein, maybe it makes more sense, if you're going to whitelist on
>     the basis of an attribute on-boarding process, to still give people the
>     chance to select a non-boarded IdP and then simply say "not boarded, 
> this
>     is what's got to happen first..."
> 
> 
> Yes, I like this. This allows a user to recognize that their institution 
> needs
> to do some work to support their research goals, and possibly causes them to
> request of their institution that they support these categories.
> 
> Taking the other approach, where the identity provider doesn’t show up in
> discovery, will probably make the user go away or use an unaffiliated 
> identity
> provider for access. It does nothing to prompt the identity provider to 
> support
> these categories.

Practically though you need a mix of these two approaches.

It is certainly useful to the community for Jim's SP to have a
nice error page that suggests to the user how she can
communicate her needs to her IdP operator in the hope that the
IdP operator will be responsive and begin releasing attributes
and participating in SIRTFI.

In practice, however, that process can take months, even
years.  Most researchers, their PIs, and their funding
agencies need demonstrable progress sooner than that.

So that same page has to in my opinion point to the IdP of
last resort options. It cannot only tell the user to
communicate with the IdP operator and then wait. 

Thanks,

Scott K for LIGO