|Eve L. Maler||Mar 4, 2007 8:57 pm|
|Tom Scavo||Mar 5, 2007 7:25 am|
|Eve L. Maler||Mar 5, 2007 8:55 am|
|Tom Scavo||Mar 10, 2007 9:34 am|
|Eve L. Maler||Mar 11, 2007 8:45 pm|
|Tom Scavo||Mar 12, 2007 6:39 am|
|Paul Madsen||Mar 26, 2007 7:57 am|
|Paul Madsen||Mar 26, 2007 8:22 am|
|Tom Scavo||Mar 26, 2007 9:24 am|
|Paul Madsen||Jul 19, 2007 6:32 am|
|Tom Scavo||Jul 19, 2007 10:07 am|
|Paul Madsen||Jul 19, 2007 10:20 am|
|Tom Scavo||Jul 19, 2007 11:27 am|
|Paul Madsen||Jul 19, 2007 2:09 pm|
|Subject:||Re: [security-services] Comments on Tech Overview rev 13|
|From:||Tom Scavo (trsc...@gmail.com)|
|Date:||Mar 5, 2007 7:25:47 am|
Nice comments, Eve.
On 3/4/07, Eve L. Maler <Eve....@sun.com> wrote:
Comments on Tech Overview rev 13 dated 21 Feb 2007 All line numbers are from plain PDF
- 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.
Actually, the word "business" appears over a dozen times. I agree that alternate wording would have wider appeal.
- Same bullet item: Is it really true that "control for [establishing and maintaining shared identifiers] can reside with the users"?
Absolutely. If you believe that users should control attribute release, then it's only a short hop to the notion that users should control identifiers as well (there's not much difference between attributes and identifiers anyway). Also, at the SP we can give the user the option of binding their identifier (or not) using an asynchronous protocol (e-mail, e.g.) that does not disrupt the normal SAML flow.
- End of Sec 1.2: Is the list of post-V2.0 deliverables up to date?
Probably not, and it will never be able to keep up. Why not simply provide a pointer to the SSTC home page?
- 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.
No, I think this is a black hole and should be avoided in the Tech Overview.
- 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 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.
Should "Advanced Concepts" go after section 4?
In addition to authentication context, would artifacts be a good candidate?
Perhaps. If you decide to do this, I volunteer to write a section on artifacts.
Maybe identity provider discovery?
- 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?
I would avoid that, if possible. A section on ID-WSF in section 5 might be desirable, however.
- 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!)
Good point. Since this requires a change to the diagram, can I make another suggestion (at the risk of being pedantic)? A flow diagram illustrating request-response exchanges should not have an odd number of steps. The culprit in this case is step 2, which is really a pair of steps.
- 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.
But this isn't unique to ECP.
- 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.
Wouldn't it be better to give an overview of ID-WSF (good luck!) in a separate subsection in section 5.