Shibboleth Developers

[Tom Scavo <>]

On Fri, Sep 24, 2010 at 11:20 AM, Scott Cantor 
<>
 wrote:
>
>> 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.

I'll take a look at that, thanks.

> I don't think we'll achieve any consensus even within a federation on
> exactly what an IdP should do in particular cases.

I don't doubt consensus will be difficult. The incentive for trying to
specify IdP behavior boils down to the isRequired attribute on the
<md:RequestedAttribute> element. Unless we provide some guidance, SP
operators will have trouble with that, I think. It's a support issue
really, and one I'd rather avoid.

Like it or not, the federation will be forced to articulate the
meaning of the isRequired attribute, so the question is whether or not
the IdP has the right knobs (as you say) to support deployments within
any given federation.

As an example, an IdP behavior that will resonate with SP operators
is: either the IdP returns ALL required attributes or no attributes
whatsoever. If "no attributes" means an error condition, that's fine I
guess. As long as the SP operator understands the consequences of
setting isRequired="true", we should be okay.

Tom