Re: [security-services] Tech Overview outstanding issues

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

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.