-----Original Message-----
From: Philpott,
Robert [mailto:rphilpott@rsasecurity.com]
Sent: 27 October 2005 18:27
To: Conor P. Cahill; Sarno,
Giuseppe [MOP:GM15:EXCH]
Cc: saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] SAML2.0
SSO & identity management
Hi Giuseppe,
It’s a good idea to also check our
errata document. Some questions you have might have been addressed by the
TC in that document. Our plan is to update the specs with these
corrections. The SAML 2.0 errata document is at: sstc-saml-errata-2.0-draft-18.pdf. Item PE-6 states:
Description: When
using the nameid-format:encrypted type of name identifier in SAML assertions
and protocol messages, it is not possible to communicate the format of the
unencrypted identifier as part of the assertion or message. This concept
was derived from Liberty
which only used it for persistent identifiers. Since we also support
other formats in SAML 2.0, the agreement on the unencrypted form (prior to
encryption/after decryption) must be done out of band.
Options: In
[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.”
Disposition: During
the conference call of April 12 the TC accepted this option.
From: Conor P. Cahill
[mailto:concahill@aol.com]
Sent: Thursday, October 27, 2005
11:34 AM
To: Giuseppe Sarno
Cc: Philpott, Robert; saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] SAML2.0
SSO & identity management
Giuseppe Sarno wrote on 10/27/2005, 11:23 AM:
The other thing strange (to me anyway)
(also looking at 2136)
is that the NameIDPolicy format has
persistent/transient/encrypted and etc..
This means I can either have a persistent
ID or an encrypted ID in the resulting Assertions, which I think one
shouldn't preclude the other.
The
thought behind encrypted was that the IdP would choose whether or not the ID is
encrypted depending upon the channel through which the assertion was delivered
to the consuming party. This came about because of one of Liberty's web services
invocation models where an assertion is delivered to party A to be delivered to
party B through a web service invocation and the encrypted ID was used by the
IdP to prevent party A from learning the ID for the user at party B.
So encryption wasn't thought to be a decision made or requested by the SP on an
authnRequest, but rather a security decsion by the IdP when the assertion is
generated (based upon the IdP's security policies).
Conor