InCommon metadata support

["Cantor, Scott" <>]

This is probably more of a -participants discussion, but I'll leave it to
Tom to decide whether to move it...

On 2/17/14, 3:43 PM, "Andrew Morgan" 
<>
 wrote:
>
>Unfortunately, we do have email addresses in @oregonstate.edu, and they
>DO 
>conflict with some of our usernames.  I assume at least some of them are
>not the same person.  We'll be looking at this closely, of course.
>
>Do you think we should resolve this before we federate and use these
>EPPNs?

Strongly, IMHO, if you're talking about actually passing out an EPPN
containing something that could be the email address of a different
person. At minimum, to do that you'd have to be certain every application
you released it to wasn't going to misuse it. I really don't think you
want to go down that road. Honestly, I don't think I've never heard that
case come up before.

>Our current usernames contain the person's last name, so we do process
>some username changes when a person's legal name changes (and the person
>requests a username change).  I'd like to create future usernames that
>are 
>less prone to change (such as initials+numbers).

Ours also contain the last name, and they change, but we still don't
reassign. That's really an independent choice you make. I would not have
gone forward with an EPPN based on it if we had reassigned them.

>If we continue to allow changes, should we stop reassigning old usernames
>to new people?  I see notes about this in the discussion of
>eduPersonPrincipalNamePrior, but I'm interested in more real-world,
>practical advice of what works and what doesn't.

Practically, apps simply assume non-reassignment, and the impact of that
is simply situational. More enlightened SPs really care, to the point of
wanting to know ahead of time.

So it again becomes a major per-system evaluation mess, or simply not
talking a lot about the issue, and I think that really isn't a practice to
follow.

I don't think there's any doubt that if EPPN were defined today, it would
require non-reassignment.

There are certainly newer attributes that attempt to more precisely
address it, but there is little hope of significant migration toward
something when all the real movement is toward email address. And of
course that's not defined as non-reassignable either, but again, most
vendors using it are certainly not dealing with the fact of that.

All IMHO.

-- Scott