how would we suggest improving the user experience at this SP

[Cantor, Scott]

On 6/4/14, 10:57 AM, "Steven Carmody" <steven_carmody at brown.edu> wrote:
>
>I was then presented with an error page:
>
> > There seems to be a problem with your account.
> > We have not received your email address from your identity provider
>(IdP). This might be because your home organization IdP is not releasing
>your email address.
> > Please see your home organization's IdP administrator. See our
>Attribute Release Policy for more information.

Well, the result is going to be bad no matter what, but the best that
seems possible to me is:

Don't say "problem with account", because it's very unlikely to be that. I
would just say that the service received insufficient information about
you to continue, and I would link to either the IdP's errorURL, something
like InCommon's error handling script, or failing that, you have to punt
and say something rather like the above, though I wouldn't phrase it that
way.

The best we can do is standardize the metadata that identifies the path to
take, and we did that, it's errorURL. A web link is by far the simplest
way because that gives the IdP operator full discretion. They can explain
what to do, or they can say "forget it, you can't use your login with that
service".

>1) This site is a member of InCommon, and is clearly supporting Higher
>Ed Identity issues, but for unknown reasons this is NOT an R&S site. If
>it were, my IDP would have released the desired attributes.

That helps get the attribute, but it dioesn't solve the problem of what to
do when you don't get it. There's no magic wand for a good user experience
in the case that it will fail by definition.

>2) This seems to be a "big" SP hosting many services, which may explain
>why no R&S. I'm told that all of the services require the same
>attributes, tho. What might prevent this site from being tagged as R&S ?

That's really an InCommon question, but one entityID hosting many services
is just a bad model. It defeats the purpose of having the entityID, and
leads to problems like this.

>3) There was no indication up front during the Login process that
>attributes are requested or required. Where should that have been done ?

Unless the IdP is offering a consent UI, there's nothing to be done.
Nothing the SP does will make the IdP release the data, and you wouldn't
know whether the data would be released or not, so what good would telling
you be? (I say "you" but picture the average user who doesn't have any
knowledge of this, they have no idea what any of this means, so explaining
up front that you'll be asking their IdP to get an email address means
nothing to them.)

This is really all about what's behind the scenes, and while there may be
cases where expressing attribute requirements can facilitate a protocol
behavior, the user never gets very involved in this, unless you add
consent.

>4) There was no indication of the SP's entityID value. My IDP admin
>needs that value in order to construct an Attribute Release Filter.

That's something that we handled by creating a service page that outlines
the technical requirements, and the error page we give directs
administrators to that page (so we don't give a user the entityID, but we
say "here's where to point your geek").

>Interestingly, this text does not agree with the RequestedAttribute
>elements in the metadata entry.

And they serve essentially no purpose in most workflows.

>     We're sorry. It appears that something has broken on our system.
>Don't worry, the web support team has been notified and will fix this
>issue as soon as possible.

I love those messages. I picture alarm bells and sirens and some big
war-room handling 404 alerts.

>What should it do ?

There are no good answers, but I honestly believe the recommendations we
put together for InCommon are about the best one can do with a dumb
browser and no consent UI (or at least no presumption of one).

Ultimately, if you're a US campus and you publish directory data for all
non-hidden users that includes email address, the reason you're not
releasing basic directory attributes for those users to any service is
that you don't want to federate. And so you should not be in the DS.
That's my honest opinion. I can't fix Europe, they have a harder problem;
we have it easy and are deliberately making our life harder, which leads
me to assume we all have stock in Google.

-- Scott