managing untrusted metadata

[Peter Schober]

* Tom Scavo <trscavo at gmail.com> [2018-04-26 20:06]:
> This comment is similar to the previous one but since InCommon is
> mentioned, let me ask: How do folks manage specific entities in
> federation metadata (InCommon or otherwise) that happen to be
> untrusted? As you know, just because an entity is registered by a
> federation does not guarantee the metadata can be trusted. Please
> share your experiences here.

There are two aspects here, the first Scott answered: The "untrusted"
aspect from the discussion subject/topic was about people not
sufficiently trusted to automatically load SAML metadata from them
over the network, due to all kinds of changes that might happen to
that metadata.
That's not an issue with all remote metadata loading, especially not
from federation operators such as InCommon.

The other aspect of "trusted metadata" which you may be hinting at is
one I care a lot about when it comes to attribute release (or
NameIDs, doesn't matter as under EU law it's all PII now) and for me
it boils down to "sufficient checks performed during registration"
(and we'll have varying defintions for "sufficient"):

Are the data structures in an SP's SAML Metadata signallings its
desire/need for data simply a wishlist to
$mythical-present-giving-deity by some clueless person?
Or has this information been reviewd/vetted by someone who understands
(1) data protection principles such as minimalism and (2) what most
IDPs of the intended target community are actually willing & able to
release? (Trivial inverse correlation: the less the SP asks for the
more likely it'll be that more IDPs will be able to interoperate.)

(Federations such as InC do not perform such reviews/vetting due
liability issues within the most litigious region on the planet.)

I know my own registration practices well ;) so I can document policy
for our community to follow that says "Release whatever the SP
requests IFF the registrar is eduID.at" -- and it would still be
somewhat safe/sane because the metadata that mediates this request has
been through some form of due diligence (rounds of asking "Do you need
this data?" and "What for you need this data?"), and it was pointed
out what our IDPs are capable of releasing (and what not) and what
they are likely to actually release, etc.

Now if I studied the registration policies of other federation
operators (all 50+ of them in eduGAIN) I might find others who do
"acceptably similar" things, and so I could recommend to our community
of IDPs to "Release whatever the SP requests IFF the registrar is A or
B or C or D or X", covering a lot more ground without raising the risk
level significantly. (And we could even make up some layer of
indirection that says "Registrars that have vetted these kinds of data
within metadata" and we could recommend policies based on that one
indirection instead.)

None of that is likely to lead anywhere, of course, so for now we're
stuck with trying to get R&S (and CoCo) deployed, and try people to at
least use consent (i.e., allow the subject to use the service at their
own risk) for the other 90% of SPs.

-peter