Re: [saml-dev] SAML 1.1 Technical Overview (11 May 2004)

["Eve L. Maler" <Eve.Maler@Sun.COM>]

Hi Tom,

Thanks very much for taking the time to send these comments.  We can try 
to correct errors at some point, though obviously this isn't quite as 
high-priority right now as completing the SAML V2.0 cycle.  I have 
copied John Hughes, the main author of the original document, and I'll 
consult with him on this.

Regarding the general issue of terminology in SAML V1.x vs. V2.0: In 
large part, when we worked on SAML V2.0 we chose to adopt terminology 
suggested by the Liberty spec contributions because of their better 
applicability to the problem space and growing acceptance by 
technologists in the field.  In the V1.1 Technical Overview we retained 
the previous terminology for obvious reasons -- to retain consistency 
with the matching older specs.

Thanks again,

	Eve

Tom Scavo wrote:

> This message records some notes regarding the following document:
> 
> Technical Overview of the OASIS Security Assertion Markup Language
> (SAML) V1.1 (11 May 2004)
> http://www.oasis-open.org/committees/download.php/6837/sstc-saml-tech-overview-1.1-cd.pdf
> 
> I apologize in advance for not sending these notes earlier in the process.
> 
> - [lines 60--72]  In light of SAML 2.0, where "asserting party" and
> "relying party" are referred to as "identity provider" and "service
> provider", respectively, why introduce new terminology at this time? 
> (Perhaps this is simply a timing issue.)
> 
> - [line 146]  Delete extraneous hyphen.
> 
> - [line 161]  The SOAP 1.2 namespace URI is erroneously listed.  This
> should be the SOAP 1.1 namespace URI (see line 184, e.g.).
> 
> - [line 165]  Delete superfluous line.
> 
> - [line 197]  Delimit line by XML comment markers.
> 
> - [line 204]  Insert comma after "e.g.".
> 
> - [line 205]  Should be "it's", not "its".
> 
> - [line 228]  Deprecated identifier used.
> 
> - [line 291]  Using SAML 2.0 terminology, the "Responder" and
> "Artifact Receiver Service" are called the "Artifact Resolution
> Service" and Assertion Consumer Service", respectively.
> 
> - [line 312]  Replace "an HTTP GET of the form provided below" with
> "an HTTP GET request (see URL below)"
> 
> - [line 322]  Assuming line 307 is correct, line 322 should refer to
> "step 6", not "step 7".  (Actually, this brings up an interesting
> point.  It might be more efficient for the Inter-site Transfer Service
> to generate the assertion, but it is certainly easier to let the
> Artifact Resolution Service do this.  In any event, this is most
> likely an implementation issue that should be avoided here.)
> 
> - [line 327]  Delete the first occurrence of the word "back" and
> change the second occurrence to "made".
> 
> - [line 328]  Should be "establish", not "established".
> 
> - [line 337]  Replace 'on JavaScript "auto-submit" action' with 'of a
> JavaScript onload handler'.
> 
> - [line 343]  The reference to "HTTP Form" in step 6 should be "HTML Form".
> 
> - [line 357]  Replace "HTML FORM" with "HTML form".
> 
> - [line 359]  Replace "HTML FORM will contain an input or submit
> action" with "HTML form will contain a submit button and/or JavaScript
> onload handler".
> 
> - [line 361]  Replace 'an "auto-submit"' with 'a JavaScript onload handler'.
> 
> - [line 363]  Replace "Assertion Consumer" with "Assertion Consumer Service".
> 
> - [line 366]  Replace "is the returned" to "is then returned".
> 
> - [line 369]  Insert a comma after "As previously described".
> 
> - [line 372]  Replace "Replying" with "Relying".
> 
> - [line 379]  Using SAML 2.0 terminology, the "Responder" and
> "Artifact Receiver" are called the "Artifact Resolution Service" and
> Assertion Consumer Service", respectively.  Also, what happened to the
> Authentication Authority in this diagram?  (It is needed, I think.)
> 
> - [line 385]  This line says the user is redirected to the Inter-site
> Transfer Service yet the diagram indicates the redirect is to the
> portal.  Which is it?  (Indeed, should the redirect be to the
> Authentication Authority?)
> 
> - [line 388]  I don't believe the "portal application" is responsible
> for redirecting the user to the Inter-site Transfer Service.  This
> should be the job of the Authentication Authority, shouldn't it (or
> should this be an implementation issue)?
> 
> - [lines 389--390]  How is the URL of the original resource preserved?
>  Is there a TARGET parameter?  If so, what components at the source
> site must handle a TARGET parameter?
> 
> - [line 400]  Assuming line 391 is correct, line 400 should refer to
> "step 6", not "step 7".
> 
> General questions about section 4.3:  How does the destination site
> know which source site to redirect to (the so called "introduction
> problem")?  Does the destination site redirect to the portal or to the
> Authentication Authority?  How is the TARGET communicated to the
> source site?  (It seems the Authentication Authority should support a
> TARGET parameter, rather than the portal.)
> 
> Since this document is final, it's water under the bridge at this
> point, but section 4.3 seems to raise more questions than it answers. 
> Perhaps this use case should be left to SAML 2.0?
> 
> Hope this helps,
> Tom Scavo
> 

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com