Shibboleth Developers

["Tom Scavo" <>]

On 6/22/06, Chad La Joie 
<>
 wrote:
> You might be able to argue that for this particular profile you could
> imply that the relying party was attempting indicate that a cached key
> should be used by the lack of the EncryptedData/EncryptedKey element but
> that's hardly a standard for doing it.  That's an optional element
> according to the XML-ENC spec so the lack of it could mean anything.

If there is no EncryptedKey element in the request, the responder has
to look elsewhere for the key.  Once found, the responder can use this
key to encrypt the response or use another key shared by the two
parties.

Personally, I think it's better to limit the responder's choices to
two (instead of three):

1. Encrypt the response using a new key
2. Encrypt the response using the same key the requester used to
encrypt the request

I don't see the benefit of switching gears on the requester by using a
different key (unless it's a new key).

Tom