Fail on resolved RequestedAttribute isRequired=true

[Stefan Santesson]

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.

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.
It would not be wrong to have an option to allow the IdP to fail and put
up an error, but I don¹t think I need it.

/Stefan


On 14/07/15 16:34, "users on behalf of Cantor, Scott"
<users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

>On 7/14/15, 10:24 AM, "users on behalf of Tom Scavo"
><users-bounces at shibboleth.net on behalf of trscavo at gmail.com> wrote:
>
>>On Tue, Jul 14, 2015 at 10:03 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>>>
>>> Nominally, the intent of saying something's required is in fact to
>>>tell the IdP that it may as well fail because the app won't run.
>>
>>Yes, but what does it mean to say "the app won't run?"
>
>It will fall over, basically. It means a bad thing will happen.
>
>> No one wants to
>>put up an error page, not the IdP nor the SP. The user experience
>>would be awful.
>
>Then that doesn't leave much...somebody has to. We have historically
>argued it should be the SP, but I think we all know how that's gone.
>
>> So it seems to me: the IdP must respond, the SP must
>>handle the response, and a positive user experience must be salvaged.
>
>The point of isRequired is essentially to signal that there can't be a
>positive experience, or that best case the SP will be putting an error
>page up. The theory would be that an IdP in that situation pretty much
>knows exactly what would be said to the user about the problem, since
>it's the IdP deciding not to release the required data.
>
>>As an aside, InCommon metadata doesn't support the isRequired XML
>>attribute on the <md:RequestedAttribute> element for this very reason.
>>The emphasis should be on providing a positive user experience, so
>>flagging an attribute as "required" serves no practical purpose.
>>Indeed, one could argue that if an attribute isn't required, it
>>shouldn't be in metadata in the first place.
>
>Aside from all the technical reasons that falls down, optional attributes
>are simply things that improve the application experience but aren't
>essential. Common example would be a persistent ID in a library app that
>can store search history.
>
>-- Scott
>
>-- 
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net