Title: Message
Many
thanks,
I'll
look into this document.
Giuseppe.
-----Original Message-----
From: Philpott, Robert
[mailto:]
Sent: 27 October 2005
18:27
To: Conor P. Cahill; Sarno, Giuseppe
[MOP:GM15:EXCH]
Cc:
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.
Rob
Philpott
Senior Consulting
Engineer
RSA
Security Inc.
Tel:
781-515-7115
Mobile: 617-510-0893
Fax:
781-515-7020
Email:
I-name: =Rob.Philpott
From: Conor
P. Cahill [mailto:]
Sent: Thursday, October 27, 2005 11:34
AM
To: Giuseppe
Sarno
Cc: Philpott, Robert;
Subject: RE: [saml-dev] SAML2.0 SSO &
identity management
Giuseppe Sarno wrote on 10/27/2005, 11:23 AM:
Hi
thanks,
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
