InC Research Participants

[Tom Barton <>]

To circle back, I remain curious about the cilogon experience 
specifically, as a case study perhaps.

Jim, do you follow up in some way only if the user's message bounces? 
What do you do?

I wonder: in non-bounce cases, might it be informative if, as a 
temporary data gathering exercise, someone (maybe me, I dunno yet) 
followed up with IdP contact N days later to ask about how the message 
was addressed? That second message either gets a response perhaps 
containing a substantive account, or not. Useful data either way.

Thanks,
Tom

On 9/1/2016 3:10 PM, Scott Koranda wrote:
> 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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature