RE: [security-services] Tech Overview outstanding issues

["Lien, Jim \(ext\)" <jimlien@rsasecurity.com>]

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: Eve.Maler@Sun.COM [mailto:Eve.Maler@Sun.COM] 
Sent: Wednesday, September 27, 2006 6:34 PM
To: security-services@lists.oasis-open.org
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.