Incoming binding urn:oasis:names:tc:SAML:2.0:bindings:SOAP is not enabled for (SP) :::

[Tom Scavo]

On Sun, Nov 26, 2017 at 7:10 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 11/26/17, 3:38 PM, "users on behalf of Tom Scavo" <users-bounces at shibboleth.net on behalf of trscavo at gmail.com> wrote:
>
>> This is great news. It means an SP deployment can choose to support
>> SAML2 on the front channel only. No signing certificate needed in SP
>> metadata.
>
> There's nothing stopping that now

Well then I guess I didn't understand what you meant by "we're going
to turn off the auto-querying functionality in 3.0?" If the SP emits a
query, it needs a signing certificate in metadata, full stop.

> and if you need a key for encryption, then there's no advantage to omitting it for signing.

That's one way to look at it :-) An alternative view is that every key
in metadata is a liability. If you don't need it, get rid of it.

If SP 3.0 can be tuned to not query, the following configuration is possible:

1) Do not support SAML1 (there is only one IdP in eduGAIN metadata
that does not support SAML2)

2) Do not accept artifacts (i.e., do not expose an
AssertionConsumerService endpoint that supports the HTTP-Artifact
binding)

3) Do not query for attributes (i.e., assume attribute push)

4) Publish a single use="encryption" certificate

This focuses attention on encryption as it should. The resulting
deployment is easier to understand and therefore easier to
troubleshoot and maintain.

Tom