<NameIDPolicy> and NIM with NameIds other than urn:oasis:names:tc:SAML:2

In SAML 2.0, I’m a bit confused about some of the wording with respect to using Name Identifier Formats other than urn:oasis:names:tc:SAML:2.0:nameid-format:persistent – particularly in the context of processing rules for NameIDPolicy and in the Name Identifier Management Profile.

For example, in an <AuthnRequest> what does it mean to have a <NameIDPolicy> with a Format=urn:oasis:names:tc:SAML:2.0:nameid-format:transient and AllowCreate=false? This seems to be a contradiction. Is it just implied that this is not allowed?

What does the AllowCreate attribute mean when used in a <NameIDPolicy> element that has a format of urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress or one of the similar formats? I’m guessing that the intent was that the AllowCreate attribute was only applicable to Name Identifier Formats that represented pair-wise identifiers linking principal accounts between an IdP and SP (i.e. urn:oasis:names:tc:SAML:2.0:nameid-format:persistent and any other that might be defined that perhaps wouldn’t have the same pseudonym privacy constraint but would still ‘link’ accounts). However, I don’t see any normative text in the specs that call out specific rules for questions like I’ve posed here. Maybe I’m missing something in all this - was this left intentionally open for some specific reason?

In a similar vein I’m unsure what types of Name Identifiers are intended to be used with NIM. Some of the wording in the spec seems to imply that NIM is only applicable to identifiers that are created and persisted in order to link/federate user accounts (urn:oasis:names:tc:SAML:2.0:nameid-format:persistent being the only defined identifier that exhibits those qualities). Other wording in the spec seems to leave the door open for a larger scope of usage for NIM.

In general I think my confusion arises from overloaded usage of name identifier format. SAML2 has included the account linking types of identifiers from Liberty but still allowed for other types. However, the spec sometimes seems to forget the scope of possible format values and presume the reader knows the intent in a particular context.

Any clarification would be appreciated,

Brian

saml-dev message