Shibboleth Developers

[Peter Williams <>]

------------

 

 

We definitely don't have that now, no. The reason is that in most cases,

what you want to be able to do is link to the IdP from *outside* it to tell

it "hey, produce a response to SP Foo". That is *not* IdP-initiated, and

that's the point I was trying to make.

 

-- Scott

 

I don't know if anyone really is asking for an unguarded idp-initiation endpoint. It’s not obvious who is asking for the new use case of a third-party invoking a (guarded) idp-initiation endpoint (though it sounds interesting). Third party initiation is not obviously part of the original SAML use case, cited earlier. I'm surprised that Library Science folks (the traditional Shib community) are so advanced in their security modeling.

 

 

One can also look wider open community, to determine the consensus on the issue of whether the self-initiated-by-IDP concept is even “coherent”. Is support and testing of idp-initiation by the IDP itself even a component of the Liberty Interoperable interoperability testing plan (that the Shib community doesn’t participate in, as with software assurance testing)? Is it mandatory? Can we look to Test Case G, in http://www.projectliberty.org/liberty/content/download/4160/27946/file/Liberty_Interoperability_SAML_Test_Plan_v3.1.pdf to answer those questions?

 

Should we henceforth use the terminology of “does Shib support unsolicited responses”?

 

This notion of the unsolicited response support seems more primitive than flows and profiles. It begs the question: how does the design prepare for a flow/profile to exercise unsolicited response making, when interoperating with other vendor’s SAMl2 implementations?