OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

Subject: Re: [security-services] Tech Overview outstanding issues

Here are the rev 10 links:

PDF without change bars:
PDF with change bars:

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 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.)


> 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.

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