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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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