...
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 | 2.3.4 |
The "name of missing attributes" might lead to some SPs mentioning the friendly names or their local human readable attribute names. This might lead to inconsistencies. It would be more consistent if the specification said that this value should present a space-delimited list of attribute names in urn:oid:#LDAP OID# format or as declared by the SP in its RequestedAttribute elements. | Lukas | |