Default NameIDFormat Metadata Elements

Rod Widdowson rdw at steadingsoftware.com
Thu Sep 15 06:34:07 EDT 2016


TLDR: rathole & hair splitting.

> There are at least two federations (I know of) that check for
> consistency between the protocolSupportEnumeration string and the
> endpoints (not the NameIDFormat). 

Which way? I'd assume that an nnnService would require an associated protocol but not vice versa.

> 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.

I don't see anything in the spec which supports your MUST:

> A whitespace-delimited set of URIs that identify the set of protocol 
> specifications supported by the role element

supported != advertised

> 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.

Actually, AFAICS, the spec is stronger than that - it infers that any SAML2 support by the _ENTITY_ requires that in the
protocolSupportString, not limited to the RoleDescriptor element.

> For SAML V2.0 entities, this set MUST include the SAML protocol namespace URI,
> urn:oasis:names:tc:SAML:2.0:protocol
 
Note that it says entities, not Descriptor.  That feels wrong, but I cannot find an errata so I cannot check.  I'm hoping that Scott
will jump all over this and tell me why I'm wrong.

R





More information about the users mailing list