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: SAML 1.1 Technical Overview (11 May 2004)


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


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