RE: [security-services] Comments on bindings-13

Rats - missed a couple of comments...

 

Line 545: says that "authentication
statements" may be distributed across assertions.  Shouldn't
this say "Assertion statements" since an assertion can contain any
of the assertion statement types?

 

Also... regarding my suggestion to
rename the "assertion consumer" to "artifact consumer"
in the Browser/Artifact profile. Lines 395-405 of section 4.1 also refer to the
"assertion consumer" service for both profiles.  Here, it is
referring to an assertion consumer in the general sense, independent of how the
assertion eventually arrives at the destination.  I'm fine with
this, but folks were confused when the artifact was sent to the "assertion
consumer URL". Perhaps we could refer to the service in the general sense
as the "assertion consumer service" or the "SAML consumer
service" and then:

 
The Browser/Artifact Profile
     could describe redirecting to the "Artifact Receiver interface URL of
     the SAML consumer service"

 
The Browser/POST Profile could
     describe POSTing the form to the Assertion Receiver interface URL of the
     SAML consumer service"

 

Rob
Philpott

RSA Security Inc.

The Most Trusted Name in
e-Security

Tel: 781-515-7115

Mobile: 617-510-0893

Fax: 781-515-7020

mailto:

 

-----Original Message-----

From: Philpott, Robert 

Sent: Tuesday, April 02, 2002
11:06 AM

To: oasis sstc
()

Subject: [security-services]
Comments on bindings-13

 

These comments are from an expanded internal review here at
RSA.  Sorry I couldn't get these late last week.

 

 
Global comment - while the term "Requester"
     is defined in the glossary, "Responder" is not.  Both are
     used throughout the bindings spec.  Suggest a global
     "s/responder/authority/" (or add responder to the glossary).

 
Sections 4.1.1.4 and 4.1.1.5 - The description of these
     steps in the Browser/Artifact profile refer to the "assertion consumer" service at the destination site. The
     "assertion consumer" term is also used in the Browser/POST
     description.  But in the Browser/Artifact Profile, this service is
     not an assertion consumer - it is an artifact consumer and thus should be
     renamed. Substitute "artifact" for "assertion" in
     lines 475, 479, 482, 483, 498, 499, 505, 506, and 514.

 
Lines 495, 514, 728: The phrase "exposed over
     SSL..." sounds strange to folks since what we're doing is preventing
     the URL from being exposed to attack. Recommend "protected by
     SSL...".

 
Line 608: s/must MUST/MUST/

 
Line 679: replace "browser/artifact" with
     "browser/POST"

 
Line 711: The "Submit" button should not be
     included in the HTML FORM body that "MUST" be used.  Lines
     765-775 contradict this explaining how to avoid using the submit
     button.  Thus, line 711 should be deleted.

 
Lines 765-775: First, the Note seems out of place since
     it is indented immediately following a comment about
     <ConfirmationMethod> which has nothing to do with it. 
     Recommend removing the note and inserting the following paragraph after
     line 744:

 

"Posting the form can be triggered by various means.
For example, a "submit" button could be included in the HTML FORM
described in Step 2 by including the following line:

<INPUT TYPE="Submit"
NAME="button" Value="Submit">

This requires the user to click the Submit button in order
for the POST request to be sent. Alternatively, Javascript can be used to avoid
the user interaction:"

           
[include the javascript from lines 767-775]

 

 
Line 838: refers to [AES], but an [AES] reference
     doesn't exist in the References section on pp 26-27.

 

 

 

Rob
Philpott

RSA Security Inc.

The Most Trusted Name in
e-Security

Tel: 781-515-7115

Mobile: 617-510-0893

Fax: 781-515-7020

mailto: