RE: [saml-dev] <NameIDPolicy> and NIM with NameIds other than urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

["Scott Cantor" <cantor.2@osu.edu>]

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

It probably needs some kind of clarification, but a strict read would imply
it's nonsense. Transient is a little unusual though, since it generally
represents another identifier, and you could read it less strictly. Probably
will need to be errata.

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

Just what it says it means, you can create a new one (or not). If that's
nonsense for a deployment, then the flag doesn't apply.

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

Why? What's the difference? Account linking is something the SP does, as far
as I'm concerned. It has no place in the SAML protocol.

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

It's usable with anything (except transient). Explicitly. Where does it say
otherwise? There are some particular rules in some cases that might apply to
one format or another, but otherwise there are no restrictions.

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

Because if it's not precluded, it's allowed. The whole point is that
"persistent" is *not* particularly special (apart from the privacy
orientation). There's nothing overloaded about it, IMHO. People want to read
account linking into the protocol, but it's not there. That's not part of
this specification, it's a deployment issue. You can link accounts with SAML
1.1 perfectly easily, which is why all the existing formats behave exactly
the same way in this protocol as persistent does.

-- Scott