Here are the rev 10 links:
Source:
http://www.oasis-open.org/committees/download.php/20644/sstc-saml-tech-overview-2%200-draft-10.odt
PDF without change bars:
http://www.oasis-open.org/committees/download.php/20645/sstc-saml-tech-overview-2%200-draft-10.pdf
PDF with change bars:
http://www.oasis-open.org/committees/download.php/20646/sstc-saml-tech-overview-2%200-draft-10-diff.pdf
I added the ID-FF comparison section and Prateek's attribute usage
section, and did a few smaller edits. Ugh, I just realized I forgot
to delete the old section 4.4.5! Will do that in next version;
sorry about that. (If we can go through all the substantive issues
below in our call, I can turn this around into a rev 11 quickly,
with Paul's help. Paul has been experimenting with DocBook
conversions; perhaps we can get an update on that and our options on
the call.)
Jim Lien has kindly offered to help with diagrams. There may be a
few that need updating/creation after tomorrow's call.
Tom Scavo has kindly offered to supply some code examples. It looks
like he's just about done with a set, which I can include in the
next rev.
Eve
Eve L. Maler wrote:
> General:
>
> - Should we consider adding "code examples" for some or all of the flows
> shown? Could be published separately as a zip file or something.
>
> - Should we consider alternative ways of publishing this document, e.g.
> as a series of web pages? Everyone seems to think that having a formal
> doc with nice pages is worth having; how much trouble are we willing to
> go through for an additional presentation? (I'd want to convert to
> DocBook or similar for that! Not willing to do in the short term.)
>
> - I will add a section comparing SAML2 to ID-FF.
>
> - I will add Prateek's new 4.5 content/instructions.
>
> Specific:
Many of these are still open, but I disposed of a few.
> 430: (The post-it comments are all from Jim Lien.) Should we expand
> coverage of the artifact binding in the Tech Overview, or let it slide?
He said it looked okay, so I deleted this comment.
>
> 573: Should we expand the description of security provided by SAML
> here? Jim's comment gets cut off in the PDF, so here's the whole thing:
> "Security is such a vital part of SAML, that I think this section needs
> more explanation. We should state what SAML offers instead of stating
> guidelines that are already in our main specs. ie. "SAML allows for
> message integrity by supporting XML digital signatures in
> request/response messages. SAML suports public key exchange either out
> of band or included in request/response messages. If additional message
> privacy is needed, SAML supports sending request/response messages over
> SSL 3.0 or TLS 1.0." There are other security features that should be
> covered here such as the security levels of the different bindings, and
> the fact that both the IDP and SP can create opaque handles to represent
> the user's account for privacy issues (something Libery really
> emphasizes)."
>
> 591: Move this section later and add coverage of extensibility and
> post-V2.0 work?
>
> 642: Should we add an "advanced topic" section on the Holder of Key
> concept?
>
> 726: Should we add an "advanced topic" section on the notion of using
> RelayState conventionally to hold the URL of the desired resource at the
> SP?
>
> 730: Small issue: If we mention RelayState here at all, we should
> introduce the concept briefly ahead of time.
>
> 782: Does Figure 15 incorrectly show POST for the AuthnRequest? I don't
> believe it does (anymore).
>
> 820: Any opinions on showing the artifact response delivered via a
> redirect vs. SOAP? I haven't touched this graphic yet; suggestions
> welcome for how to show the redirect without getting too confusing. (On
> line 823, Jim agrees with Rob.) Obviously the diagram needs an updating
> no matter what we decide.
>
> 843: Reflect RelayState convention in this section?
>
> 895: Is a step missing in the explanation? How should the diagram
> change? (The SLO diagrams are a lot less precise than the SSO diagrams,
> which is fine with me, but I'm happy to add more detail wherever anyone
> wants it.)
>
> 900: I tend to agree with Jim that having a section for the multiple-SP
> logout is overkill. The different-binding question is well taken care
> of in the SSO sections, I'd say.
Did I already agree on the last call to chop this set of scenarios
down? I didn't do that yet.
> 928: How to deal with NameID registration?
>
> 930: Should we provide additional accurate detail about NameIDs in the
> federation diagrams? How should this be done?
>
> 953: Again, explain how the desired resource is identified through
> reference to RelayState? At least remove the TARGET discussion.
>
> 963: Discuss AllowCreate here?
>
> 1025 and 1035: What example should be used to show an attribute being
> sent along in an SSO assertion -- is the membership number example
> inappropriate?
>
> 1043: I'll incorporate Prateek's text, which we discussed this week,
> into a new 4.5 that replaces 4.4.5, but should we go to the extent of
> providing a diagram, as we did before? If so, what should it look like?
I guess we can look at the one I accidentally left in, to see if we
want something similar...
>
> 1098: (Simple edit that I'll make. Listed here for completeness.)
Done.
>
> 1135: I think we removed an old artifact URIs, but no name ID formats,
> right?
>
> 1140: What-all should be listed here? Is this little list in this
> bullet complete as far as it goes?
>
--
Eve Maler +1 425 947 4522
Technology Director eve.maler @ sun.com
CTO Business Alliances group Sun Microsystems, Inc.
