<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">#It is what it is, I'm afraid. ePPN is universally supported so it</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">#makes sense to build an app around that assumption. Of the two</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">#characteristics you mentioned, non-reassignability is critical (for</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">#some apps) so in that case you have to workaround it.</span><div>
<font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">We can ensure that ePPN is never reassigned, but we can't ensure that </font></div><div><font face="arial, sans-serif">it is not occasionally changed (for example when a person has two </font></div>
<div><font face="arial, sans-serif">and we consolidate). For those apps that require it, we recommend</font></div><div><font face="arial, sans-serif">that they listen to our message broker for events that indicate an ePPN</font></div>
<div><font face="arial, sans-serif">change.</font><div class="gmail_extra"><div><div dir="ltr"><br>- Michael<br><br><span style="background-color:rgb(255,255,255)"><font size="1" color="#990000" face="comic sans ms, sans-serif">Michael Hodges<br>
Enterprise Middleware, Identity and Access Management<br>University of Hawaii, Information Technology Services<br><a href="mailto:michael.hodges@hawaii.edu" target="_blank">michael.hodges@hawaii.edu</a><br>808-956-7195 (GMT -10:00)</font></span></div>
</div>
<br><br><div class="gmail_quote">On Tue, Sep 2, 2014 at 10:40 AM, Tom Scavo <span dir="ltr"><<a href="mailto:trscavo@gmail.com" target="_blank">trscavo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
(again off-topic...you can shift this over to the InC participant's<br>
list if you want)<br>
<div class=""><br>
On Tue, Sep 2, 2014 at 3:12 PM, Ken Weiss <<a href="mailto:ken.weiss@ucop.edu">ken.weiss@ucop.edu</a>> wrote:<br>
><br>
> It would be nice if every institution<br>
> that's part of the InCommon federation agreed on an identifying attribute<br>
<br>
</div>Like it or not, that attribute is ePPN, which I believe is supported<br>
by almost all IdPs. The eduPersonTargetedID attribute is supported by<br>
less than half of the IdPs (based on incomplete data cited earlier).<br>
The eduPersonUniqueId attribute is new and virtually non-existent.<br>
<div class=""><br>
> and assured that the value for that attribute would be stable for the<br>
> duration of an individual's association with the institution and never<br>
> re-assigned to a different individual.<br>
<br>
</div>That's a tall order but note that stability and non-reassignability<br>
are independent characteristics.<br>
<div class=""><br>
> I thought that was EPPN, but clearly, I thought wrong.<br>
<br>
</div>It is what it is, I'm afraid. ePPN is universally supported so it<br>
makes sense to build an app around that assumption. Of the two<br>
characteristics you mentioned, non-reassignability is critical (for<br>
some apps) so in that case you have to workaround it.<br>
<span class=""><font color="#888888"><br>
Tom<br>
</font></span><div class=""><div class="h5">--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div></div></div>