Shibboleth Developers

[Chad La Joie <>]

As I said, there is no specification that says how to do this.  What you 
propose may make sense in certain circumstances, but it's not a standard 
way to do it and there is no way for either party to stipulate that 
they're expecting the relying part to do it this way.

Tom Scavo wrote:
> 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

--
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124