Disallow eppn/affiliation to be asserted by the wrong IdP

[Peter Schober]

* William Spooner <william.spooner at eaglegenomics.com> [2012-10-11 14:15]:
> Two of the IdPs I'm dealing with do not define scope in their
> metadata. I'm working with local XML documents, so could add
> manually, but take Peter's point that this adds potential for
> (potentially insecure) issues on any metadata update.

If you're willing to do the work you can still to it (check for valid
metadata, check for valid signatures on the metadata, check the
validUntil date, etc.) and merge with your local changes.
Or simply let some script notify you when the entity you're interested
in changed remotely so that you can pull in those changes to your
local copy.
But that's creating extra work for you, for not yet clear benefits.

> I admit I'm trying to bend non-edu IdPs to fit the securely scoped
> shib eppn/affiliation model. It looks like it _could_ be done, but
> increasingly feels like a hack. Which is a pity as eppns make much
> more forgiving REMOTE_USER IDs than persistent_ids. Oh well - back
> to relying on persistent_id and custom application code. 

edu or non-edu isn't the issue (and the "e" in ePPN is for "edu", of
course, so you already know that ;)
Everyone can use the existing metadata extensions to specify
"registered" scopes. You can also define your own attributes making
use of scopes and then check for those.
But one of the requirement for scope checking is that the attribute is
scoped in protocol messages, i.e., that the type of the attribute is
a scoped one. Which, somewhat counter-inuitively, is not the case for
the RFC mail attribute (if that is of interest; you were not clear at
all what attributes scoped you'd need to check).
-peter