OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [saml-dev] searching for a use case


> > My only *guess* is that they are trying to allow for 
> protection of the 
> > data independent of the TLS provider (so, perhaps, if they put a 
> > separate TLS endpoint in the network nearby the IdP, the data would 
> > still be protected all the way to the IdP).
> But what would be the function of this middle "endpoint"?  It 
> would have to be outside the firewall to warrant encryption, 
> but in that case, what could such an endpoint do with an 
> attribute request whose NameID is encrypted?

The TLS endpoint can be inside the firewall, but not co-located with
the IdP.  Just because you're inside the firewall, doesn't mean we
trust the network and potential interlopers.

Encrypting the NameId prevents anyone other than the IdP from
decrypting it so they don't see the content.  However, the NameID
*was* encrypted with a symetric key and that key is included with
the message (encrypted with the IdP's public key) so the IdP will be 
able to decrypte the NameID (by retrieving the symetric key using 
its private key).

Note that the response also has encryption requirements along the
same lines, but reversed (symetric key encrypted using SP's public


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]