Some comments:
General: Code examples would be a significant amount of work (assuming
it must all compile)
I can investigate converting to DocBook. Not sure I can commit time to
actually converting the text.
430: Initially, I thought this section could be expanded, but it is
covered in other areas of the tech overview. So, there's probably no
need to repeat it here.
843: Current text seems ok.
Eve, if you are looking for a volunteer, I would be happy to update the
diagrams.
Jim
-----Original Message-----
From: [mailto:]
Sent: Wednesday, September 27, 2006 6:34 PM
To:
Subject: [security-services] Tech Overview outstanding issues
Ultimately I just decided to list all the issues, in the hope that
interested parties will speak up. Major themes: Conventional use of
RelayState; whether we have too much/too little coverage of various
topics; whither the document as a whole.
If you want to do your own hunting through rev 09 for issues, it's here:
Source:
http://www.oasis-open.org/committees/download.php/19257/sstc-saml-tech-o
verview-2%200-draft-09.odt
PDF without change bars:
http://www.oasis-open.org/committees/download.php/19258/sstc-saml-tech-o
verview-2%200-draft-09.pdf
PDF with change bars:
http://www.oasis-open.org/committees/download.php/19259/sstc-saml-tech-o
verview-2%200-draft-09-diff.pdf
To my knowledge, the following items represent all the outstanding
editing issues on the Tech Overview. Line numbers are to the PDF
without change bars (middle link above).
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:
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?
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.
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?
1098: (Simple edit that I'll make. Listed here for completeness.)
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.
