Fail on resolved RequestedAttribute isRequired=true

[Stefan Santesson]

I don¹t want to take up too much bandwidth about this, but let me explain
how we think.

In our government federation we offer a centralised DS.
The goal of this DS is to never show an IdP that is known not to work with
the requesting SP.

The DS will have a well defined set of algorithms for filtering IdP:s.
This allows SP:s to configure their metadata so only relevant IdP:s will
show up in the DS.

Aspects to filter on is mainly LoA, attribute support and support for
mobile authentication.
IdP:s will signal their capabilities through EntityAttributes (entity
category and assurance certification).

One possible way to set up a DS filtering algorithm is to compare IdP
capabilities with required attributes on the SP side, but currently there
is no decision to go there, and frankly I doubt that we will. But we can
if necessary.

/Stefan

On 14/07/15 17:08, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

>On 7/14/15, 10:55 AM, "Stefan Santesson" <stefan at aaa-sec.com> wrote:
>
>>Another aspect/use of this is that the isRequired=true can be used by
>>Discovery services to filter out IdP:s not capable of responding,
>>preventing a request from being made at all.
>
>I can't see how, a DS has no idea what an IdP will release. Even a list
>of raw attributes supported by the IdP doesn't really tell you in any
>specific case what would happen.
>
>>This is probably how we will use it, if at all. The Discovery service can
>>compare this with what it knows about EntityCategory attributes declared
>>by the IdP.
>
>That's a different sort of filtering I think, based on EntityAttributes.
>
>-- Scott
>