[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] Web Post Profile and Conformance
-----Original Message----- From: Hal Lockhart [mailto:hal.lockhart@entegrity.com] Sent: Monday, January 21, 2002 12:13 PM To: security-services@lists.oasis-open.org Subject: [security-services] Web Post Profile and Conformance In the bindings document, the Browser Profiles (lines 377-732) the term SSO Assertion is used repeatedly. This is an undefined term as far as I know. Is it supposed to be Authentication Assertion? Apparently, that's what the Conformance folks think, as reflected in the table on line 166 in the conformance document. [Prateek Mishra] 374-376 of bindings-09 define SSO assertion using the following text: In the discussion of the web browser SSO profiles, the term SSO assertion will be used to refer to an assertion that has a <saml:Conditions> element with NotBefore and NotOnOrAfter 375 attributes present and that contains one or more authentication statements. 376 I see in the Artifact profile, we are back to "one assertion per artifact" Presumably this allows a Destination site to request an Authentication Assertion and an Attribute Assertion about the same subject. 1. Is this correct? [Prateek Mishra] We have a "mixed type" assertion model: therefore, for example, a single assertion could contain an authentication statement and an attribute statement.We are certainly staying with one assertion per artifact model in the current draft. It is simple (maybe even simple minded) but it gets the job done. 2. If so, the table in the conformance document should be fixed. [Prateek Mishra] Agreed, the contents of the third column of the Table 1 are incomplete. We are dealing here with statements which may be contained within assertions. All of the profiles may deliver any of the three types of assertion statements. It is a further requirement that web SSO always delivers a SSO assertion. The Post Profile says that multiple Assertions MAY be included. (Although in various places like line 654 it says "an Assertion.") [Prateek Mishra] I dont read 654 to imply that. I can make it more explicit to say: ..SSO assertion and (optionally) other assertions. 3. If this is the case, the table in the conformance doc should be adjusted. [Prateek Mishra] This is the same issue as in Table 1 above. 4. Given this, I don't see why implementation of the SOAP binding is mandatory, if only this Profile is supported. [Prateek Mishra] Binding and Profile are distinct entities. When we agreed that the conformance would follow the Binding and Profiles, I thought the terminology would be carried over. Shouldn't compliance with the Browser Profiles be interms of being a Source Site or a Destination Site or both? Shouldn't conformance with the SOAP Profile be in terms of Sender or Receiver or both? [Prateek Mishra] We should discuss this point further. Obviously, there are going to be issues of granularity that we need to come to consensus on. 5. The bindings doc, lines 697 & 700 says <saml:Target>. In the core document text, line 492 (and on the mailing list) this is called <TargetRestriction>. However I just noticed that in the schema it is Target, so perhaps this is a core bug rather than a bindings bug. [Prateek Mishra] We are both right here. The <saml:Target> element occurs within a higher-level container called <saml:TargetRestriction>. There may be one or more occurrences of <saml:Target> within <saml:TargetRestriction>. (More about Target to follow.) Hal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC