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