Alternative IdP Working Group

[Chris Phillips <>]

Been lurking on here for awhile, apologies for not being on the calls..

Maybe they could go, but from a business case (e.g. I need Multfactor for
service X) it illustrates the can of worms exists instead of hide it under
the carpet or it being absent during a comparative analysis.

When assessing any path to take, I would highlight or call out that
certain things are make or break decision areas and these may be them. The
features exist for a reason and if that is unique to that space, it may be
the sole reason for someone to adopt that implementation.

If you take them out of the table for readability, no problem, but maybe
create a separate section for
Unique features' and give appropriate airtime compared to the larger table?



C.


On 14-09-30 9:16 AM, "Tom Scavo" 
<>
 wrote:

>On Sat, Sep 27, 2014 at 3:38 PM, David Walker 
><>
> wrote:
>>
>> I noticed a couple of columns where
>> we might not be completely in agreement.  Here are proposed
>>interpretations:
>>
>> Support for Entity Categories (R&S).  The issue here is whether the IdP
>>can
>> be configured to release attributes automatically to any SP in a
>>specified
>> Entity Category like R&S.
>
>AFAIK, Shibboleth is the only software in the world that can leverage
>entity attributes at the IdP. If that's true, then there isn't much
>point having such a column in the table.
>
>> Support for Multiple AuthN Contexts for MFA and Assurance.  The issue is
>> whether the IdP can invoke different authentication methods based on
>> authentication contexts specified in the SAML request (e.g., the
>> Multi-Context Broker).
>
>Likewise this column is a can of worms and should probably be removed.
>First, the MCB is add-on software, not baked in, so I'm not sure it
>qualifies as an illustrative example. Moreover, I'd be very surprised
>if ANY software can process specific RequestedAuthnContext values
>out-of-the-box, especially for values not defined in the SAML2
>Authentication Context spec.
>
>Tom