[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] NameIDPolicy Format use clarification
> > We should probably list it in the section with a clear explanation of > > where it is used (and not used). > > I didn't want to list it in 8.3 because it's not a legal format. It's a > processing rule of the NameIDPolicy element only. [RSP] Yes, but section 8.3 is the section where all identifiers are listed that "MAY be used in the Format attribute of the <NameID>, <NameIDPolicy>, or <Issuer> elements". Since encrypted can be used in <NameIDPolicy> I think it should be listed here for completeness, with the caveat that it is only permitted in <NameIDPolicy>. > > > So is the assumption that if the NameIDPolicy does request an encrypted > > NameID, that the returned NameID should be a persistent identifier? > > IMO, SOMETHING should be stated to be assumed, since otherwise, the > > "...:encrypted" format is not useful. > > It is clearly stated: > > "The special Format value > urn:oasis:names:tc:SAML:2.0:nameid-format:encrypted indicates that the > resulting assertion(s) MUST contain <EncryptedID> elements instead of > plaintext. The underlying name identifier's unencrypted form can be of any > type supported by the identity provider for the requested subject." [RSP] Ooops - missed that last sentence. It is clear. > > Nothing in there is implying you have to use persistent. What did y'all do > to decide what to send before NameIDPolicy existed? ;-) [RSP] In Liberty ID-FF 1.2 it states that "of the formats defined in this specification, only federated name identifiers sometimes require encryption", so I have always presumed their use in that context. However, it actually did permit pre-1.2 identifiers to be encrypted by omitting the format or using "another unspecified value". So, I guess I was presuming they were always federated ID's unless some other out-of-band agreement was made.