On Apr 2, 2005, at 5:03 PM, Greg Whitehead wrote:
>
> On Apr 2, 2005, at 4:09 PM, Scott Cantor wrote:
>
>> PE6: Encrypted NameID
>>
>> [SAMLCore]
>> Append to paragraph ending on line 2139:
>>
>> "It is not possible for the service provider to specifically request
>> that a
>> particular kind of identifier be returned if it asks for encryption.
>> The
>> <md:NameIDFormat> metadata element (see [SAMLMeta]) or other
>> out-of-band
>> means MAY be used to determine what kind of identifier to encrypt and
>> return."
>
> It might make more sense to say that the IDP should be in charge of
> deciding whether to encrypt the ID or not and have the SP always
> request the particular kind of ID it wants. In other words, disallow
> use of "encrypted" in request name id format.
As a follow up to this, and the discussion we had on the call today, it
strikes me that a more general solution for protecting assertion data
in transit (as seemed to be the argument for supporting 'encrypted' in
the AuthnRequest NameIDPolicy) would be to introduce an SPSSODescriptor
extension attribute in metadata
WantAssertionsEncrypted
that could be used to specify that the whole assertion should be
encrypted in the response. We'd obviously have to document a way to do
that, and that might require some new schema.
Anyway, that said, I'm fine with Scott's suggested language if there's
value in only encrypting the NameID in the returned assertion (and not
any attributes).
-Greg
