> 1. When the ECP talks to the IDP, the IDP SSP Descriptor
> metadata setting it would use would be the Single Sign-On
> Service endpoint with a binding of urn:...:SOAP.
Well, I don't think it was ever a given that clients would use the metadata.
They could, but I think they usually end up having the URLs provisioned
directly.
But yes, the binding used to the IdP is SOAP.
> 2. When an SP publishes its metadata, what is the binding of
> the Assertion Consumer Service endpoint that is used by ECP
> callers. I.e., is it urn:...:SOAP or is it urn:...PAOS? Since
> the IDP doesn't really care/know about ECP, I assume the
> value should be urn:...:SOAP?
I would say it's PAOS, since that's what the binding in use is on that leg.
But whatever, should be clarified.
> 3. When the IDP is sending back a response to the ECP, it
> should only ever be sending this back to an Assertion
> Consumer Service whose endpoint is SOAP/PAOS (as answered in
> 2 above)? I.e., for a SOAP binding based AuthnRequest, the
> assertion consumer url that gets identified (whether by the
> AuthnRequest data such as AssertionConsumerServiceURL,
> AssertionConsumerServiceIndex, ProtocolBinding, or whether
> by the IDP using the default endpoint for this service) must
> have a binding of SOAP/PAOS for things to work.
I'd think so.
> 4. I assume the ECP examples related to xxxConsumerURL in
> [SAMLProf] should probably be fixed so that they correlate.
> I.e., the SP is sending a value of
> http://identity-service.example.com/abc whereas this should
> be the assertion consumer url that the IDP defines in the
> ecp:Response AssertionConsumerServiceURL?
Looks like errata in the example to me.
-- Scott
