Fail on resolved RequestedAttribute isRequired=true

[Cantor, Scott]

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