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: Comments on Tech Overview rev 13


Comments on Tech Overview rev 13 dated 21 Feb 2007
All line numbers are from plain PDF

This document is looking good!  Just a relatively modest list of
suggestions below.  Let me know if you'd prefer me to put in any of
the edits myself.

- Ideally we should apply the new OASIS template and legal
boilerplate.

- Title page: In preparation for CD, we'll need to take a look and
move some names from the Editor and Contributor lists to the special
Acknowledgments section if those people are no longer in the TC.  I
believe Prateek should also be moved up from Contributor to Editor.
And Jim Lien and Rob Philpott should be listed as being "formerly
of RSA Security".

- Table of Figures: Figures 11-13 and 25-27 seem to be repeats (was
the TOC refreshed?). There are a few other weirdnesses around
figures and cross- references to them that I'll note below.

- Sec 1, line 88: The phrase "business partners" makes SAML seem
more heavyweight than it need be, though this is the most common use
to date.  Same for "business use cases" on line 94.

- Sec 1.1, line 100: s/Single Sign-On/Single sign-on/ to match the
other list items.

- Sec 1.1, line 110: Extra space before "user".

- Sec 1.1, lines 112-124: The "Federated identity" bullet could
usefully have a brief mention of "privacy sensitivity".  There could
be a forward cross-reference to the "Privacy in SAML" section.

- Same bullet item: Is it really true that "control for
[establishing and maintaining shared identifiers] can reside with
the users"?

- Sec 1.2, line 137: I would say "extensions to and profiles of
SAML".

- Sec 1.2, line 143: Software vendors *and users* typically care
about conformance, only in different ways.

- Sec 1.2, line 165: s/This is a non-normative/It is a non-
normative/

- Sec 1.2, lines 168-172: We should revise the description of the
Errata to say they're on an OASIS standardization track etc.

- Sec 1.2, lines 173-174: Should we mention that SAMLBind also has
security considerations for specific bindings?

- End of Sec 1.2: Is the list of post-V2.0 deliverables up to date?

- Sec 2.1, line 203: s/replying party/relying party/ (I think!)

- Sec 2.1, line 204: Should we say a bit more about trust here?
Maybe it's worth pointing to Liberty discussions and guidelines
about circles of trust/federations/affiliations.

- Sec 2.2: I think it's a bit confusing to introduce a "federated
identity" before we've even gotten through the basic web SSO use
case; leave that for Sec 2.3.  SSO should be explained with as few
assumptions as possible (e.g. no local account on the SP side).

- Sec 2.3, line 285: The figure cross-reference is missing.

- Sec 3.1, Figure 4: Would it perhaps be a good idea to use the
"SAML parfait" (or a revision of it) here?  I'm personally
switching from that old diagram to the parfait in my SAML presos.

- Sec 3.1, lines 357-367: I actually think that there's enough
external interest in the authentication context stuff that we should
add an Advanced Concepts section for it.  Paul, I know you've got
writeup that might be pressed into service here.

- Sec 3.2: I would prefer to see the Advanced Concepts section go
after the SAML Components section, particularly if we add a few more
items to it.  In addition to authentication context, would artifacts
be a good candidate?  Maybe also attribute profiles?  Maybe identity
provider discovery?  PAOS?  These could be very short sections.

- Sec 3.2.1, lines 374-378: This is a little confusing still.  It's
the assertion wielder, not the actual asserting (it says
"attesting") entity, that is trying to "use" the assertion, right?
I've been using "identity-wielding entity" to talk in general terms
(in presos and the like) about digital subjects, but I fear I may
have confused things if we want to use "assertion wielder" here.

- Sec 3.2.1, lines 384-385: Can we say "predefines" instead of
"defines" and something about the ability to add your own
confirmation methods?  Also, s/, these are/:/

- Sec 3.3, line 400: s/profile  concepts/profile concepts/

- Sec 3.3, lines 401-402: Anne Anderson would want me to comment
that statements are *typically* about a subject...

- Sec 3.3, lines 407-409: s/user/subject/g, right?

- Sec 3.4.2, Figure 6: The session index is likelier to be something
like "0" or "1" than a big complicated number in real life.

- Sec 3.4.2, lines 528-535: Should there be a cross-reference to
Liberty Web Services for more information on the wider motivation
for identifier mapping?

- Sec 3.4.3, line 550: s/, refers/ in referring to/

- Sec 3.5, lines 592-594: A crisper way to state this is "Many
deployments of SAML technology have privacy requirements that SAML
is expected to solve."

- Sec 3.5, line 597: s/do not themselves enable/inhibit/

- Sec 3.5, line 603: s/identifier,/identifier;/

- Sec 3.5, lines 605-607: this bullet item about authentication
context makes an unclear case for being about privacy.  Does it
intend to say that stronger authentication and identification
mechanisms can be reserved for higher-value transactions, while
lower-value ones can be deal with using anonymity techniques more of
the time?

- Sec 3.6, line 630: Close up space before final period.

- Sec 4.1.1, line 639: s/section 2.2/Section 2.2/

- Sec 4.1.1, line 640: s/first/first,/

- Sec 4.1.1, line 658: Figure cross-reference number is missing.

- Sec 4.1.1, line 660: s/centers around/centers on/

- Sec 4.1.1, line 662: s/many of which/some of which/

- Sec 4.1.2, Figure 12 (and globally throughout all the figures): I
suspect the arrow for step 1, "Access resource", is supposed to be
dotted, not solid, because it's out of band for SAML.  (This is
probably a bug of long standing -- I'm sorry!)

- Sec 4.1.3, lines 822-824: The figure and cross-reference are
missing!

- Sec 4.1.4, line 972: s/SAML v2/SAML V2.0/

- Sec 4.1.4, line 973: s/SAML v1/SAML V1.x/

- Sec 4.2: It would be good to spend a sentence or two
characterizing the "enhanced" nature of ECPs here.  What kind of
smarts do they (have to) have, compared to unmodified commercial
browsers?  Could they be done with a browser plug-in?  (Hey, why not
give people ideas?)

- Sec 4.2.1: If there isn't an Advanced Concepts section on PAOS, I
think it's worth a few sentences here explaining just what's so
weird and wonderful about PAOS.

- Sec 4.2.1, lines 1014-1015: It's worth noting that the reasons why
the IdP and SP can't communicate could be either technical or
nontechnical/"policy-driven".  CardSpace's flows operate on the
latter assumption by design.

- Sec 4.2.1, line 1018: s/defines/utilizes/

- Sec 4.2.2, line 1022: s/between the ECP, service provider and
identity provider/among the ECP, service provider, and identity
provider/

- Sec 4.2.2, Figure 15: s/EnhancedClient/Enhanced Client/

- Sec 4.3, line 1041: s/service providers/providers/ (It's
technically accurate the longer way, but some people may think that
identity providers don't count if we say it that way.

- Sec 4.3.1, line 1050: s/SOAP over HTTP/SOAP-over-HTTP/

- Sec 4.3.1, line 1055: s/each participant/each session participant/
(for clarity)

- Sec 4.4.2, lines 1131-1133: How to revise this to resolve the
outstanding issue?

Sec 4.4.3, Figure 18: Some of the text in step 8 is getting
occluded.  I've noticed this can happen if you don't special-paste
these as metafiles (I think that was it, anyway).

- Sec 4.4.4, lines 1180-1182: s/are useful/is useful/

- Sec 4.4.4, line 1183: s/ID's/identifiers/

- Sec 4.4.4, line 1184: s/accounts,/accounts;/

- Sec 4.4.4, line 1185: Is it fair to actually say "role-based" here
rather than "group-like"?  I'm not sure the latter is clear enough.

- Sec 4.4.4, line 1186: s/anonymous service/anonymous service./

- Sec 5.1: I think it would be useful and instructive to mention the
ID-WSF SecMech-related specs in this section, to give context as to
how additional profiling can utilize WS-Security and SAML assertions
for a really complete system.

- Sec 5.1, line 1312: Holder of Key is now covered in an advanced
topic, so you could back-reference the section if you like.  At the
least, the meta-comment can come out.

- Sec 5.2, line 1325: s/Access Control/access control/

- Sec 5.2, Figure 23: Text in several steps is getting occluded.

- Sec 5.2, line 1356: The reference to the SAML Profiles spec should
also have a biblio ref.

- Sec 5.2, line 1359: The mention of the SAML Profile (uppercase
instead of lower?) of XACML v2.0, should have a proper biblio ref.


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