InC Research Participants

[Scott Koranda <>]

Hi Paul,

> The new/emerging baselines practices, in its current draft,
> will require metadata accuracy, including contact addresses.

Will InCommon Operations be verifying the email addresses on a
periodic basis to check the accuracy?

> Now let the dialogue resume on what to do in cases on
> continued non-compliance...   :)

I had hoped to hear at TechX a concrete proposal on
non-compliance. Will that not be forthcoming?

As you know I am concerned that a baseline practice will not
be a reality until well into 2018, or even later. Do you have
evidence to the contrary?

I know, as Tom Barton has said, that people want the baseline
to happen, but I am keen to hear a date so that I can make
decisions about where LIGO puts its efforts in mitigating
risks to using federated identity via InCommon.

Thanks,

Scott K for LIGO

> 
> Sorry if this has already been discussed, just joined this
> list a few minutes ago (didn't know it existed)...  
> 
> 
> 
> 
> > -----Original Message----- From:
> > 
> > [ 
> > ]
> >  On
> > Behalf Of Scott Koranda Sent: Thursday, September 01, 2016
> > 3:10 PM To: Tom Barton 
> > <>
> >  Cc:
> > 
> >  Subject: Re: IdP
> > discovery - list 'em all?
> > 
> > Hi,
> > 
> > Thinking about it from the other direction, can we learn
> > from the InCommon people on the list what processes are in
> > place now or in the future to find and fix contact email
> > addresses in metadata (for InCommon Participants) that
> > bounce?
> > 
> > It seems less than optimal to have users working through
> > failed authentication flows with SPs as the only mechanism
> > for finding problems with contact email addresses.
> > 
> > Thanks,
> > 
> > Scott K for LIGO
> > 
> > > I'm interested to understand, if possible, what impedes
> > > resolution when the user is given a reasonable error
> > > message and an email address to communicate with about
> > > it (Jim, you said this has *never* yet been successful,
> > > I think - yikes).
> > >
> > > Which address(es) is the user provided for contacting
> > > their IdP operator?  And what message text are they
> > > given in hopes that the two will lead to resolution? Are
> > > those presented as "press here to send this message to
> > > these addresses" or as instruction to send a message to
> > > those addresses including the suggested text, or
> > > something else?
> > >
> > > Thanks, Tom
> > >
> > > On 9/1/2016 2:37 PM, Basney, Jim wrote:
> > > >On 9/1/16, 12:32 PM, Tom Mitchell wrote:
> > > >>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.
> > > >Agreed. It helps when the contact email addresses in
> > > >IdP metadata don't bounce. I learned today that one of
> > > >the downsides of having the user send the email to
> > > >their IdP operators is they give up when the email
> > bounces...
> > > >Good thing we have the user also CC us so we can
> > > >follow-up.
> > > >
> > > >FWIW, I've reported the bouncing contact email
> > > >addresses in InCommon metadata to 
> > > >.
> > > >
> > > >-Jim
> > > >
> > >
> > >
> > 
>