InCommon Technical Discussions

["Farmer, Jacob" <>]

Just for some sense of understanding the scope of this, I suspect that many 
IdPs are experiencing this, but perhaps do not realize it. Looking over the 
SPs that we federate with who only require ePTID[1], most of them appear to 
be 
library or online training providers, where the only[2] impact is the loss of 
reading history or training history. And that may not be noticed by the end 
user. Basically, if I log into OnlineTrainingService, will I ever notice that 
it doesn't remember that I took Excel training last year?

I do like the idea of some commonly-available "attribute diff" tool that 
could 
make discovering this change easier. Obviously, it is something that you can 
figure out through careful testing during the IdP upgrade, but it would be 
fairly easy to overlook if you didn't specifically search for it.

Jacob

[1] We release this by default to InC members, so I can only look where we 
have explicitly released it in a bilateral federation.
[2] I know that there are cases where this is nontrivial.

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Basney, Jim
Sent: Thursday, June 8, 2017 9:26 AM
To: 

Subject: Re: [InC-Technical] ePTID changes caused by Shibboleth IdPv3 upgrade

On 6/8/17, 6:36 AM, Scott Koranda wrote:
> We will plan to notify the IdP operator of the issue, but often the
> IdPs that present this issue also have incorrect contact information
> in metadata and/or do not respond on a timescale useful to the VO, so
> it is better from the VO perspective to just use the normal vetting
> process to process the "new" enrollment and get the user back to accessing 
> the SPs.

Indeed. When CILogon attempted on Monday to notify an InCommon IdP operator 
about their ePTIDs changing, the mail bounced ("User unknown"). We're looking 
forward to the checks for contacts in metadata that are part of the planned 
Baseline Expectations Implementation [1]. I'm also looking forward to using 
the ORCID iD linking added in the recent COmanage release to help us avoid 
re-vetting users, since ORCID gives us long-lived persistent IDs. Until then, 
we have no choice but to re-enroll the users (which we're doing for another 
InCommon IdP this week).

-Jim

[1] https://spaces.internet2.edu/x/05iTBg

Attachment: smime.p7s
Description: S/MIME cryptographic signature