Re: [security-services] Technical Overview review meeting Aug 24 noonPT

["Eve L. Maler" <Eve.Maler@Sun.COM>]

SAML V2.0 Technical Overview review session
24 August 2005

Attending: Eve, Heather, Jeff, Steve, Nick, Frederick, Rob

We worked from this version:

http://www.oasis-open.org/committees/download.php/13786/sstc-saml-tech-overview-2.0-draft-07-diff.pdf

Look for "AI:" embedded within the text (added after the fact) for
action items.  Apologies to David Staggs; the teleconference wasn't
audio-recorded.

*Editing the Visio graphics:

Heather offered to help in editing these if necessary.  We don't
know of a way to do Visio<->OpenOffice.

Nick got the latest Visio file from John Hughes.


*Diffs section:

Eve proposed using the graphical device found in this document:

http://www.uazone.org/demch/analytic/draft-authz-xacml-saml-02.pdf

...for conveying structural differences.  See Figure 1.2 for an
example.  The others were in favor.  (AI: Eve.)

It appears that it will be worthwhile to list all the detailed
differences that exist, in addition to overview info like in the
graphic.  (AI: Eve.)


*IdP-initiated info:

Eve proposed moving IdP-initiated scenarios to be in front of the
corresponding SP-initiated scenarios because they're easier to
explain and have simpler (if more artificial) flows.  Then the later
SP versions could assume that part of the flow is "already covered"
and just cover the cycling to get from the SP to the IdP.  Nick
notes that "factoring out" details of the flows may confound readers
who copy the use case text that applies to them.  So we agreed to
keep each use case complete.

This prompted a discussion of the perhaps overwhelming size of the
document, though most people won't read the whole thing; they will
read only the use cases that they feel apply to them.  No changes
suggested.

Eve suggested putting motivations for the different use cases more
in the front, then point off to the detailed sections in the back.
Section 2 (which is very brief now) would be the ideal place.  The
explanations would have to be fairly high-level (e.g. they can't,
and don't want to, go into detail about binding choices) but they
can refer to IdP and SP concepts (which were introduced in Section
1).  (AI: Eve.)

Jeff suggested an additional section in between 2 and 3 for covering
more complicated concepts.  Eve suggested holding off on that for
now.  We agreed.


*Color keying in the early graphics:

Nick has suggested using the colors consistent across figures 3, 4,
6, and 10.  He volunteered to give this a try.  (AI: Nick.)

Eve noted that figure 3 is metaphorical containment, unlike the
others which show literal XML containment, and so it should look
sufficiently different from the others.  She will send her version
of this graphic (in slide form) to Nick.  (AI: Eve.)


*Flow graphics:

Eve had complained that the flows often go "backwards" -- there
isn't a left-to-right bias.  Nick believes that the entities should
be static and had edited the graphics for this goal.  This seems
appropriate, especially since there are many more SP-initiated flows
and their #1 steps are on the left.  We discussed the strengths of
this scheme vs. swim-lane diagrams.  The consensus is to keep these,
even though there's a place for swim-lanes (e.g. the Profiles
spec!).

Nick wonders if step #1 should be highlighted in some way.  Most
people think it's better to keep the #1 callout the way it is.

Steve noted that figure 14 has two steps for a form POST operation
but figure 15 has a single swooped arrow for a browser redirect.  We
debated whether the number of arrows should match; the general
consensus was that the possibility of user interaction is worth
making the diagram look different.  But it was suggested that the
arrows for steps #2 and #3 somehow get joined in a small box in the
browser labeled "user action" or something (as figure 23 does for
the SOAP intermediary) -- Jeff suggested an image of a Submit GU(I
button!  (AI: Nick.)  Redirects are still appropriate to have a
single curved arrow.

Nick asked about the appropriateness of the "(Signed Assertions)"
notations, appearing initially in figure 16; other notations also
appear in this figure, such as "Artifact Resolution Service".  There
was general support for the notations; it was suggested that the
latter notation could replace "SAML Responder" in the green box.
(AI: Nick.)


*Section 2, motivations for SAML in the intro:

Heather noted that web services wasn't one of the *initial*
motivators for SAML's creation.  Let's change the second sentence of
this intro to: "There are several drivers for the adoption of the
SAML standard, including:"  (AI: Eve.)

She also suggested changing the order of the list to: SSO interop,
then federated ID, then web services.  Others agreed.  (AI: Eve.)

Heather agreed to propose freshened-up wording for the web services
item.  (AI: Heather.)

We agreed that the "drivers" information should moved back from
Section 2 to Section 1.  (AI: Eve.)


*Section 2.1, Attribute Federation Use Case:

Eve wants the vanilla SSO use case covered before a use case that
depends on attributes, and isn't sure anyway that the text here
supports the extra attribute-related detail that now appears in
figure 1.  Nick notes that figures 12 and 13 covers some of the
subtle distinctions that figure 1 seems to address.  Should most of
the conceptual stuff in Section 4.1.1 (Concept) be moved here?  Yes.
(AI: Eve.)

We agreed that what is now figure 1 should be moved to Section
4.3.3, which goes into detail on the attribute federation profile,
in order to help explain the concept.  (The text currently
supporting figure 1 in Section 2.1 should be dropped/replaced since
it's not specific enough.)  (AI: Eve.)  Ultimately figure "1" might
need its details changed to match figure "25"; Nick can do that.
(AI: Nick.)


*Section 3.2:

We need to clarify under Single Logout Protocol that "Logout can be
initiated by a provider site (SP or IdP), not just by a user."  (AI:
Eve.)

The current short description of the Name Identifier Mapping
Protocol isn't very helpful, and the later Profile section for it
has apparently been removed (figure 24 shows roughly what it would
have to look like in terms of number of entities because it shows
two SPs).  We agreed to try and reinstate the Name Identifier
Mapping profile section if possible, and then take a look at it.
(AI: Eve for text and Nick for graphic.)


*Section 3.3, SAML Structure and Examples:

Eve noted that there are two subsections, Assertions and SOAP over
HTTP Binding (an odd pair), with examples in both of them that could
be put to a broader purpose.  She will explode these into new
subsections that illustrate more things, including perhaps:
Assertions, Artifacts, Subjects, Bindings (if we can think of useful
conceptual diagrams to support it -- don't want to duplicate the
Bindings doc which has lots of examples), and not sure what else
yet.  (AI: Eve.)


*Section 3.4, Federated Identity Principles:

This subsection is a fish out of water.  The high-level stuff in the
first couple of paragraphs should be moved up to Section 2 to form
the general "use cases" discussion of federation.  (AI: Eve.)

The NameID information should be moved to the new Subjects
subsection in Section 3.3 (that we just invented above).  (AI: Eve.)
The Attribute Statements information should be dropped, though we
want to include a mention somewhere in a conceptual explanation of
federation of the importance of attributes.  (AI: none yet; we need
to see how the new draft looks.)

The mention of Shibboleth here isn't very enlightening.  It would be
nice to add a Shibboleth sub-section to Section 3.5; we'll add the
header and ask for volunteers for content.  (AI: Eve.)

We're not sure what the focus of Section 3.4 should be (conceptual
vs. SAML components), or if it should even remain here.


*Other Frameworks:

Heather suggested that a syntax example of WSS would be useful.
(AI: Eve.)


*Additional work:

Eve (along with others?) still has some comments she'd like to have
some discussion on.  She will send these out to the list.  (AI:
Eve.)

-- 
Eve Maler                                         +1 425 947 4522
Technology Director                           eve.maler @ sun.com
CTO Business Alliances group                Sun Microsystems, Inc.