Shibboleth Developers

["Scott Cantor" <>]

> Section 2.3.3 of that document recommends an ordering that includes
> <md:ServiceName>, so presumably it would come into play. In fact,
> since <md:ServiceName> is a required child element of
> <md:AttributeConsumingService>, it is likely that both
> <mdui:DisplayName> and <md:ServiceName> will be available in metadata.
> If the latter were profiled as a more fine-grained name, maybe both
> could be displayed, I don't know.

Right. The section you're talking about is, to say the least, under
developed. I wanted to stake out the topic first because I think it has to
be covered.

> In any event, InCommon metadata will most likely contain
> <md:AttributeConsumingService> elements in the near future (no
> timeline yet). So the more interesting question is: will the consent
> engine consume <md:RequestedAttribute> elements?

uApprove just bundled the plugin I wrote for that, but it's only handled as
a way to auto-populate the release set for the consent step to approve or
disallow.

The issue is what all the different pieces (resolver, profile handlers,
consent module) do with the information, because there is no hard and fast
requirement for that in SAML, since IdPs have broad discretion. Anything we
do will sit well with some deployers and not others. It's a question of how
many knobs there are, vs. the constant chorus that there are too many knobs
and it's too hard to use.

I don't think we'll achieve any consensus even within a federation on
exactly what an IdP should do in particular cases. What matters most is what
we expect may happen as a result and for SPs (really more the applications)
to be prepared for that.

-- Scott