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 / Reference | Proposed Change or Query | Proposer | Action / Decision (please leave blank) | |
---|---|---|---|---|
1 | 2.4. returnURL | What 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. === 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 |