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


Tom Scavo wrote:
> Eve, I tried to let this go but it was causing me to lose sleep :-)

Yikes!  It's not worth that!  (And I know whereof I speak. :-) )

> This seemingly small point impacts nearly all the expository work I've
> done regarding the SSO profile.  Can we flesh this out a little more?
> Please see below.
> 
> On 3/5/07, Eve L. Maler <Eve.Maler@sun.com> wrote:
>> On 3/5/07, Tom Scavo <trscavo@gmail.com> wrote:
>> > On 3/4/07, Eve L. Maler <Eve.Maler@sun.com> wrote:
>> > >
>> > > - 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!)
> 
> My interpretation is just the opposite.  By all indications, steps 1
> and 7 are in band and in scope.  In particular, see sections 4.1.3.1
> and 4.1.3.6 in SAMLProf.

I see your point.  Although SAML says nothing about exactly how 
these steps are done, RelayState is in play starting with step 1, 
and both endpoints of the process get an explicit mention.  That's 
certainly good enough for me.

>> > 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.
>>
>> It's a pair depending on the binding...
> 
> It doesn't seem like the binding matters.  The profile specifies a
> number of round trips between a user agent and a SAML entity.  The
> flow begins and ends with a user agent.  Thus the total number of
> steps is a multiple of two.  This is true in all cases, even artifact.

It was decided to show redirects as a single swoopy arrow/step, 
whereas POST has two arrows/steps; that's what makes the difference. 
  It would be possible to show redirects differently (and I think we 
edited out one case somewhere that had a redirect in two steps?).

>> I personally don't think we need to hew to this rule.
> 
> That's fine.  It's mostly pedagogical and not worth quibbling about in
> general.  I personally find this to be a useful rule when writing
> documentation and so forth since it leads to reasonably complete
> end-to-end flows that novices can understand.

I'm game to change it -- if Paul feels like doing the graphic 
editing!  But I don't feel it's absolutely essential unless 
something thinks we're making it more confusing this way.

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