Re: [security-services] Proposed erratum resolutions

[Greg Whitehead <grw@trustgenix.com>]

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