Shibboleth Developers

["Cantor, Scott E." <>]

> I think people are used to regularly encountering situations in everyday
> life that present "some things are required and some things are
> optional". Its a straightforward concept, easy to understand. Being able
> to leverage that would require little additional user training.
> Presumably that's why it was included in the SAML metadata standard.

That isn't my argument. And it was very definitely included under the
assumption that consent would be per attribute. When you don't do that (as
neither uApprove nor Cardspace did), the feature doesn't work right.

> What's harder to understand is why the consent process is encountering
> problems with that model. I was suggesting that some discussion of the
> issues in this space might be useful.

Sure. This is long, but since you're asking for the conversation, and I
haven't written it up yet...

A basic issue is that the filtering process to choose attributes to
release (subject to consent) runs before the user gets involved. That has
to decide, right then, whether to return all of the attributes or just the
required set. That's an admin choice, not a user choice. That defeats the
central purpose of the option and turns it into a very coarse setting that
just controls whether IdPs will release lots of stuff or just the minimum
set. That will work fine, and does work now, but it doesn't serve SPs very
well.

Obviously if there *is* per-attribute consent, you would tune the IdP to
release everything and then have the user toggle optionals on and off.
That isn't my dispute, but we don't have that feature planned, and I do
happen to think users will not find that useful unless we have a way to
explain how the data would be used (and I don't think users will read that
anyway).

I think its better to have a yes/no choice, and I think other deployments
suggest that's the case. But that's just my opinion. The fact is we don't
have the feature planned, and so that creates a problem if people start
creating metadata that relies on the feature.

The other problem is the OR issue. There are multiple use cases that
affect many SPs in which the SP wants to accept any of a set of
attributes. The attribute set might be required or optional. Obviously you
can't express that right now (Tom's suggestion of using multiple sets
wouldn't work either, since the combinatorics below up).

The other case that's kind of an OR, but not exactly, is the SAML version
case. Typically the set of attribute names will be different between SAML
1 and SAML 2 (you can criticize us for that, deservedly so, but that's
just how things evolved). Obviously you can't express "requiredness" if
you have to require both a SAML 1 and SAML 2 attribute name, since one of
the two wouldn't be available depending on the SAML version used.

We could certainly limit consent to SAML 2 only, but the feature was meant
to apply to any SSO protocol (the metadata feature isn't protocol
specific). My feeling was that given all the other problems, if avoiding
isRequired solves the SAML version problem too, that's just more reason to
do it.

The "follow the standard" issue I alluded to is that there's no question
that the intent behind isRequired was to indicate that the SP *MUST* have
an attribute to operate. So any implementation that's playing games in
order to solve the OR problem is not playing by the book, and it makes the
metadata unclear at best. I would rather we avoid "hidden" semantics in
the information. That doesn't mean not putting some things OOB, it just
means not treating the metadata as anything other than what it says. The
most likely way to do that is to list things as optional and let the
filtering process naturally prune out the stuff that's not right for the
SAML version or not supported by the IdP because it uses CN instead of
displayName, etc.

At the end of that, you can't support users limiting information flow to
"more data" or "less data", but if your set of attributes is "an ID, a
name, and an email address", do we really care? That's 99% of the use
cases here, IMHO, as I keep saying. When there are more exotic
requirements, it's almost always a contract situation or an SP where the
admin's going to be involved anyway.

So that's our discussion, in a large nutshell. We don't have to break on
isRequired, and we can handle it, but we think it's best avoided right now
in favor of handling alternative attribute naming, and that the latter
enables more use cases.

Nothing precludes defining a totally different mechanism in the future,
and federations that start supporting the syntax we have should relatively
easily be able to spin that into a new syntax later, so I don't think we
lose anything by starting simple.

-- Scott