[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Comments on Tech Overview rev 13
I've finally gotten around to reving v13 to reflect I can update on tomorrow's call In the meantime Tom, if you want to send me some text on artifacts I'll include. paul Tom Scavo wrote: > Nice comments, Eve. > > On 3/4/07, Eve L. Maler <Eve.Maler@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). > > I agree. > >> - 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? > > Like this? > > http://en.wikipedia.org/wiki/User:Trscavo/Sandbox/SAML_2.0#Identity_Provider_Discovery_Profile > > >> - 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. > > Tom > > -- Paul Madsen e:paulmadsen @ ntt-at.com NTT p:613-482-0432 m:613-302-1428 aim:PaulMdsn5 web:connectid.blogspot.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]