You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

This consultation opens on 14th April 2020 at 17:00 CEST and closes on 14th May 2020 at 17:00 CEST.

Background

The goal of this specification, "SAML V2.0 Metadata Deployment Profile for errorURL Version 1.0” is to offer specific guidance on how a service should inform users of non-technical shortcomings of logins.

As indicated in the specification:

This profile provides a set of conventions around the use of the attribute that extends the usefulness of the feature such that Service Providers can make more effective use of the feature when encountering conditions that can plausibly be remedied by the user’s Identity Provider. The profile is compatible with existing uses of the attribute such that Service Providers can easily determine if the profile is supported by the Identity Provider.

The document contains four main sections:

  • An introduction that describes the purpose of the specification.

  • A profile description that defines a convention for the syntax for the errorURL

  • User interface guidance

  • Examples

The specification has been prepared by the REFEDS Best Practice around Error Handling Working Group and is now being made available for public consultation according to the REFEDS Participants Agreement.

Overview

Participants are invited to:

  • Review and comment on the proposed specification for SAML error handling.

Following the consultation all comments will be taken back to the REFEDS Error Handling working group for review and if appropriate the White Paper will then be forwarded to the REFEDS Steering Committee for sign-off and publication on the REFEDS website as per the REFEDS participants agreement.


The document for the consultation is available as a Google doc in Suggestion mode or as a pdf attachment.  All comments should be made on: consultations@lists.refeds.org, added to the google doc as a suggestion or added to the change log below.  Comments posted to other lists will not be included in the consultation review.

Change Log

We recommend adding changes to the Google doc directly via suggestion mode.  For those who would prefer not to use Google,  please use the change log below referencing the pdf attachment.


Line / ReferenceProposed Change or QueryProposerAction / Decision (please leave blank)
12.4. returnURLWhat seems to be missing from this specification is a way to let the user continue to do what he/she came to do: use the SP.

If the federate login via the institution did not work, e.g. because of MISSING_ATTRIBUTES, the user may now end up at an Idp error page. Regardless of the root cause of the error, it is unlikely the IdP will be able to mitigate this problem within the time the user wants to get access to the SP. Effectively we have now silo-ed the user into a place where there is no obvious way to continue, and the user is 'lost' to the SP, as the SP is several redirects away. That is a rather poor user experience.
However, the SP might be offering other means of login to the service, e.g. social or guest IdP login, or perhaps access to the SP with less privileges. With this proposal, there is now no easy way for the user to return to the SP and use an alternative.
I would therefor propose to add a capability to let the SP add a 'return URL' to the Optional Placeholders so a user may, after having been informed by the IdP of the issue, may return to the SP and continue to work. In this way the IdP error page could present a link or button to allow the user to "Return to the service'.

===

2.4. returnURL

An optional URL set by the Service that the IdP can present to the end user to allow the user to continue using the Service via some other authentication method. The returnURL MUST appear within the query string of the URL. This requirement allows the URL-encoding rules to be less ambiguous.

===

It is already very inconvenient the user was not able to use federated login. We should not punish the user double by blocking him from continueing to do his work.

Niels
2



  • No labels