Date: Thu, 28 Mar 2024 12:51:27 +0000 (UTC)
Message-ID: <343156145.111.1711630287714@wiki-prod.refeds.org>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_110_150716706.1711630287711"
------=_Part_110_150716706.1711630287711
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
Consultation Response call - 18 June 2020
Consultation Response call - 18 June 2020
Attendees=
h1>
Consultation Feedback and Responses
=
Working Specification Document
Notes
- The current specification, for one scenario it works very well - when t=
here is no logical or reasonable way for a user to do anything other than w=
ait for the IdP resolves whatever needs to be done (or tells them it can=E2=
=80=99t be resolved).
- For another scenario, however, where research service providers or prox=
ies, there might be a number of ways for a user to continue to use the SP r=
egardless of whether they could use the initial IdP. The best scenario is t=
hat the user continues to use their home institution, but if that doesn=E2=
=80=99t work for whatever reason (and it could be any number of reasons), t=
he SPs probably have a number of other ways for the user to log in. For exa=
mple: The proxy at CERN offers 4 different ways to log in to their services=
, though the probably allow different qualities of services. We should allo=
w the user the ability to return to some location offered by the SP that su=
pports an alternate way to authenticate (or to something that doesn=E2=80=
=99t require authentication at all).
- Users should not get stuck in holes if not needed. We should also stay =
away from making authZ decisions on behalf of the SP. If we support a fallb=
ack URL, the IdP can present better information to the user as informed by =
the SP.
- This is not currently how any other protocol works. Anything involving =
callback URLs mean you have to handle callback redirectors (would require i=
ntelligence on the IdP side to watch for this). Maybe we could use an SP er=
rorURL? If you do want the experience of multiple options for the user, the=
n offer a link that the user can click on to report the error to the IdP.&n=
bsp;
- We could pass the same transaction context back to the SP in real-time =
to support of the above.
Consensus: keep the protocol simple for now. If we see in a year=
a strong need for extending, we will do that. What we have will not preclu=
de those potential future additions. Explain in the text a bit more about w=
hat the SP can do (Fredrik has already added this to the text)
------=_Part_110_150716706.1711630287711--