how would we suggest improving the user experience at this SP

[Peter Schober]

* Steven Carmody <steven_carmody at brown.edu> [2014-06-04 16:57]:
> I've been trying to use a Shib-enabled SP, and I've been having some 
> problems. I'm wondering if this group might provide some "best practice" 
> info addressing some of the issues that I encountered. I'd prefer to not 
> identify the site. Rather, I think the problems I encountered may be 
> evident on lots of sites, and are more general than just this one site.

Actually the error message you're greeted with is one of the
friendlier ones I've seen. "Error 0x1234567890" or simply "Access
denied" are still more common than "sorry, you can't play because your
IDP did not release the mail attribute".

[ Slight tangent: I wonder if as an SP I should go one step further
and turn such error pages into HTML forms with one large, friendly
button saying "Get me access" that will notify the technical contact
given in SAML metadata for the IDP the subject used to authenticate,
providing all the detail s/he may need to act upon it (date, time,
client IP, attributes needed, attribtues [not] recieved). ]

> 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.
> 
> 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 ?

I think there are specific InCommon groups to contact about that.
Sorry, I don't have a more specific suggestion.

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

I don't know of a single service that does this as part of the login
process and I'm not convinced it needs to be done. Consent at the IDP
is something else, of course.

> 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 could have been part of the (improved, see above) error page at
the SP, but either way the IDP will have it in its log files (together
with your userid/netid and the list of attributes released), so no
reason to bother the poor user with this, IMO.
I.e., we shouldn't use subjects as carrier pidgons for technical
details and error messages between federated components.

> 7) If I retry the whole process, I am immediately redirected to the main 
> web page for the site. No Discovery Service, no IDP. I understand that. 
> But, instead of seeing an error, I'm redirected to a useless url.

That sounds... useless?

> What should it do ?

Be consistent in what the application needs and what SAML metadata
states the application needs.

Use the info provided in SAML metadata about the IDP used to give a
better error message than "talk to your administrator", such as giving
the subject a preformatted message with the required details and a way
to send that to the published contact address at the institution.
(Taking that further leads to the form button I mentioned above.)

> thanks for any and all suggestions !

If they are a member of a federation you're also a member of, I'd take
it up with other members of the federation and/or the federation
operator to send a joint statement to the SP in question, making
concerte suggestions for an improved UX.
In some cases it might be better to organize that jointly but have
everyone send individual requests. Either way, it's more of a
political question, not a technical one.
Of course making sure this error condition does not occur (i.e.,
getting an entity category assign or looking at this case closely if a
new category might be warranted, if existing ones are not applicable)
should also be pursued, but improved error handling is independent
from that.
-peter