Of course, if we were to do that, we would have to have protocols
to enable it on the back channel (a SOAP interface accessed
directly by the SP) and on the front >channel (a redirect of
the user's browser from the SP to the IdP). The front channel
is needed for IdPs that store session information on the user's
This should not be forced to be a back channel ( a SOAP interface
accessed directly by the SP)
Agreed. That was the point I was making.
as there are requirements to have other requestor types than
However, this I don't understand. The front channel (via an HTTP
Redirect) would only be available when there was a browser around.
Are you saying that the SSTC should profile client protocols other than
HTTP? Or that the non-browser client would still utilize an HTTP
Also, in my mind, the nead for the front channel interfaces have
revolved around two scenarios: a) client side state that the receiverr
needs in order to be able to process the request, and b) enabling early
implementations by SPs that don't want to deal with SOAP.