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] SAML2.0 SSO & identity management

Title: Message


From: Giuseppe Sarno [mailto:gsarno@nortel.com]
Sent: Friday, October 28, 2005 4:30 AM
To: Giuseppe Sarno; Philpott, Robert; Conor P. Cahill
Cc: saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] SAML2.0 SSO & identity management


There are a lot of clarifications.

My question is would they make V2.0 ?

[RSP] Not quite sure what you mean.  These are all clarifications to the SAML 2.0 spec.  They do not change the behavior of the 2.0 specs that have been approved as an OASIS standard.  They are errata intended only to clarify what the committee “meant” in the spec in places where questions have arisen.


If something comes up where the committee decides it wants to change the actual behavior, then that would require us to issue a new version of the specs (e.g. a v2.1).


But the items in this errata document do not fall into that category.  They all describe edits to the docs that reflect what the committee meant for the specs to say.


Make sense?



-----Original Message-----
From: Sarno, Giuseppe [MOP:GM15:EXCH]
Sent: 28 October 2005 09:22
To: Philpott, Robert; Conor P. Cahill
Cc: saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] SAML2.0 SSO & identity management

Many thanks,

I'll look into this document.



-----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.



Rob Philpott
Senior Consulting Engineer
RSA Security Inc.
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
I-name:  =Rob.Philpott

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:

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).


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