Default NameIDFormat Metadata Elements

[Tom Scavo]

On Wed, Sep 14, 2016 at 2:25 PM, Klingenstein, Nate
<nklingenstein at calstate.edu> wrote:
> IdPv3 on install appears to generate metadata like:
>
>     <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0">
> ...
>         <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
>         <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
>     </IDPSSODescriptor>
>
> and
>
>     <AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">
> ...
>     </AttributeAuthorityDescriptor>
>
> Attempts to kill the back channel aside, should these be the same?

There are at least two federations (I know of) that check for
consistency between the protocolSupportEnumeration string and the
endpoints (not the NameIDFormat). In the above example, on the
IDPSSODescriptor element, I would expect at least one SAML2 binding
and one SAML1 binding. A SAML1 SingleSignOnService endpoint MUST be
included to account for the "urn:mace:shibboleth:1.0" protocol string.

On the AttributeAuthorityDescriptor shown above, I would expect a
SAML1 AttributeService endpoint only. If there were a SAML2
AttributeService endpoint but no SAML2 protocol string, the entity
runs the risk of being filtered at the federation border.

Tom