Minutes for FOCUS call, April 5

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

Attending:
Eve, Prateek, Rob, Scott, Rebekah, Greg, Cameron, Tom, Alberto, Ari,
Darren, Brian, Rick, Jeff, RLBob (possibly plus others I missed?)

Don't forget to go buy your SAML T-shirts (and trivets and teddy
bears)!

   http://www.cafepress.com/oasis_open/509675

prateek mishra wrote:
> 1. SAML 2.0 informational documents
> 
> (a) Executive Overview
> 
> http://www.oasis-open.org/apps/org/workgroup/security/download.php/12103/sstc-saml-exec-overview-2.0-draft-08-diff.pdf


Eve has published a new draft, with change bars in the PDF.  Changes
are getting more and more minor.  We anticipate voting on CD status
at the next quorate call.

> (b) SAML FAQ and open questions
> 
> http://lists.oasis-open.org/archives/security-services/200503/msg00116.html

Eve updated the FAQ.  There have been a number of outstanding
questions collected over time, which we can answer if/when we wish.

Rebekah attempted an answer to the J2EE/.NET interop question, and
this occasioned discussion on the list about multiple ID attributes,
along with issues of signing and interactions with the WSS TC.

We need to distinguish "signing SAML" from "using SAML in other
specs" in such a way that the SAML specs don't govern the usage.  If
there's an interop question about how to use SAML in WSS, we
shouldn't be responsible for answering that.  But it would be handy
to at least direct people to the place where they can get a
definitive answer, and we can provide factual information about
details of SAML that may be misunderstood.

The factual tidbit in the current case is that SAML does not allow
other ID attributes on the elements where it has an ID attribute
already.  We can't provide a definitive answer about the situation
wrt whether the XML family of specs allows or disallows multiple ID
attributes (though Eve claims they disallow them!).

Rebekah will take this input and continue to work on questions and
answers for the FAQ.  We'll cycle on the list.

> Discussion:
> 
> i. 
> http://lists.oasis-open.org/archives/security-services/200504/msg00000.html
> 
> (c) Technical Overview
> 
> _http://www.oasis-open.org/apps/org/workgroup/security/download.php/11511/sstc-saml-tech-overview-2.0-draft-03.pdf_

Eve and Prateek will work on fleshing out this spec this week.  (Eve
is woefully behind.)  John H. has just provided the relevant source
file for revision.

> (d) Request for SAML 2 slide set
> 
> http://lists.oasis-open.org/archives/security-services/200503/msg00118.html

Prateek has some slightly obsolete material that he will send out.
Eve will do the same.  Scott has some "SAML history and motivation"
material that he'll send out.  Perhaps Hal will be able to combine
these and share the results.

> 2. Other drafts (recent updates)
> 
> (a) Errata
> 
> http://www.oasis-open.org/apps/org/workgroup/security/download.php/12042/sstc-saml-errata-2.0-draft-03.pdf

Note that Jahan isn't on today's call.

> Discussion:
> 
> i. Small potential erratum 
> http://lists.oasis-open.org/archives/security-services/200504/msg00004.html

We may want to clarify the text describing the cookie format, since
the current text may imply that each field should be individually
base64-encoded; rather, the whole thing should be base64-encoded.
It would be good to add an example to remove all ambiguity.

We explored why base64-encoding is even needed; it's sort of
theoretical hygiene, but mostly it's just a borrowing from ID-FF.

We'll ask Jahan to add this as a PE.

> ii. Proposed erratum resolutions
> http://lists.oasis-open.org/archives/security-services/200504/msg00007.html

We'll ask Jahan to add Scott's proposed solutions to the next draft.

PE1: Relay State for HTTP Redirect:

The existing language was copied and pasted from another profile and
was inappropriate.  The proposed wording from Scott fixes this.

PE2: Metadata clarifications:

Scott has isolated one small part of this issue that is amenable to
clarification; the rest has a wider scope and is likely to be
discussed in the V2.x era.

We'll ask Jahan if he's willing to start a V2.x issues list parallel
to the errata document.

PE3: Supported URL Encoding:

Scott suggests that this is really just a live issue, not an erratum.

We'll ask Jahan/whoever to add this to the issues list.

PE4: SAML 1.1 Artifacts:

Scott's proposed text clarifies that previous artifact formats are
no good in V2.0.

PE5: Rules for NameIDPolicy:

We deferred discussion of this until we get to the broader topic.

PE6: Encrypted NameID:

Scott's proposed text clarifies that you can't ask for a specific
kind of encrypted ID because there's only a single construct for
encrypted IDs.  We could consider alternatives to allow for more
request capability, but this is more invasive.  Greg questioned why
anyone would even want to ask for an encrypted ID; Prateek mentioned
complex end-to-end scenarios.  Scott was going for a minimally
invasive solution in his proposed text.

PE7: Metadata attributes WantAuthnRequestsSigned and
AuthnRequestsSigned, and PE9: Clarification on SP
AuthnRequestsSigned and the IdP WantAuthnRequestsSigned SP metadata
flags, together:

Scott's proposed text should be reviewed, particularly by people who
participated in the interop.

> iii. Text for PE8
> http://lists.oasis-open.org/archives/security-services/200504/msg00015.html

PE8: SLO and NameID termination:

Tom has proposed some text here clarifying the relationship (or lack
thereof) between Manage Name ID requests and SLO request.  Rob had a
recollection that we had specifically intended to connect them and
will go back and doublecheck.

> (b)  XPath Attribute Profile
> 
> http://www.oasis-open.org/apps/org/workgroup/security/download.php/12064/draft-saml2-xpath-attribute-profile.sxw
> 
> Discussion:
> 
> i. 
> http://lists.oasis-open.org/archives/security-services/200503/msg00119.html

We discussed the motivation for this profile.  Cameron's original
interest came from wanting to do Liberty data services.  Eve
suggested documenting the use cases a bit more before digging into
the profile, and also noted that any discussion will tend towards
confusion because XPaths point *into* XML documents, and yet the
profile proposal contains a whole URN that would be used as a
NameFormat identifier.

More discussion to come.

========

New topic added to today's agenda:

"previously established an identifier usable by the requester":
http://lists.oasis-open.org/archives/saml-dev/200503/msg00000.html

There was quite a bit of discussion on the list about AllowCreate.
Scott's contention is that the spec shouldn't change; rather, the
issue is about back-end implementation of the spec, and doesn't want
to change the spec and find that we haven't actually solved the
problem.  He suggests that the issue is not about the nature of
persistence itself, but the manner in which the identifier is
managed.  We may want to nail down some edge cases in the spec,
though, and provide more AllowCreate guidance.  Greg wonders if
persistent identifiers are nonetheless unique in being candidates
for this attribute.  We are struggling with the fact that interop
will suffer given the current circumstance.

Note that AllowCreate isn't related to name ID management, perhaps
despite appearances.

Eve suggests that we want to push the limits of understanding the
implementation scenarios before considering what minimally might
have to be clarified in the spec.

We used to have a more explicit notion of termination; having a
"creation" semantic in this attribute has therefore lost some
parallelism.

We attempted a consensus reading: Regardless of the name ID format
used (although "transient" might need slightly special treatment),
the IdP needs to maintain state about what name ID it issued to what
SP for each principal, and even if it's got some back-end
persistence, the creation of that ID was more about the
circumstances of its creation *for use by that SP*, and not about
inherent creation.  It's creation of an association, not
(necessarily) creation of an ID.  In this context, "termination"
also means something different from what might otherwise be assumed.

Liberty's Federate flag was more explicit about this association
process, but baked in the account linking that we don't want to bake
in here.

Scott believes that it's an implementation choice, not a conformance
choice, to link accounts when AllowCreate is true.

Jeff and others note that a narrowly defined profile could nail down
the relevant details.  Brian wonders why the original profile
shouldn't be in charge of doing this.

Greg asks a critical question: Is a terminate request advisory ("you
can toss this"), or an explicit instruction ("don't use this again
unless I send you a new AllowCreate=true")?  Scott notes that the
spec text doesn't impose behavior on the other guy, but states what
the sender itself plans to do.

Brian observes that there are some critically relevant MUSTs in the
conformance spec around avoiding/implementing name ID management
complexity that are far away from the relevant text in the profile
spec and elsewhere.  For example, there are some seeming MUSTs about
AllowCreate in the core spec and the SSO profile that seem to change
in interpretation.  But Scott points out the caveats present in the
core spec.  Prateek suggests that the core MUSTs around AllowCreate
become null and void for certain operational modes.  Brian asks for
more clarity around all of this.

Jeff suggests that a lot of this differentiation should be captured
in implementation as "configuration knobs and buttons".  So the
selection of operational mode might be a setting.  Probably there
need to be more outreach materials around this.

Scott agrees to suggest some errata text for line 2143 of the core
spec and line 521 in the profile spec to un-conflate the two senses
of "create" that are causing confusion, while reserving
implementation flexibility.  Brian also notes line 251 of the
profile spec, seeming to promise "ensuring" interoperability, but is
willing to believe that this is too strong a reading!

There is a general sense that precluding the use of transient
identifiers with all this would be useful.  Scott will account for
this in his proposed text.

-- 
Eve Maler                                      eve.maler @ sun.com
Sun Microsystems - Business Alliances     x40976 / +1 425 947 4522