Re: [security-services] Comments on Tech Overview rev 13

[Paul Madsen <paulmadsen@rogers.com>]

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