Minutes for 14-Dec SSTC focus group con-call

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

Attending:

Steve Anderson
Scott Cantor
Eve Maler
Rebecca Metz
Prateek Mishra
Ron Monzillo
Rob Philpott
Darren Platt

>    1. Electronic ballot update

It's apparent we're going to move ahead with a new public review.  We 
need to get it started immediately.  The specs have been uploaded to the 
repository, and they've started writing the official request to Mary 
McRae.  She's prepared to send out the notice very quickly.

Because we did the electronic ballot (which doesn't end till tomorrow), 
if we start the public review tomorrow, it can't finish until January 
14.  In order to have a vote after that, we'd have to vote on January 
15, which is a Saturday.  Moving the vote to a Monday would mean a 
month's slip because of the "train schedule" at OASIS.

However, it turns out to be possible to run the tail end of the public 
review concurrently with a vote to proceed to OASIS Standard balloting.

This whole schedule presumes that the changes we're making are not 
substantive.  Right now, the only area where we anticipate such is the 
authentication context classes.

>    2. Spec status

Prateek has created "diff" (change-bar) and plain versions.  The diffs 
reflect all changes since we first published cd-01 (which we didn't 
really intend, but that's okay).  We will plan to do an "accept all 
changes" before publishing the ultimate cd-04.

Authentication context class schemas issue (Scott):

We were relying solely on tools before, but wherever the tools were 
flawed, problems crept through.  Now the scope of the issue is such that 
we can eyeball the whole thing and make better value judgments than the 
tools can.  The XMLBeans compiler that PingID has been using has been 
the most strict.  XSV (from Henry Thompson) has been letting some 
illegal constructs slip through.

In security terms: The classes are trying to describe how you 
authenticate, and they're split into different forms of authentication. 
  They amount to "sets" of technologies.  Some classes say: The form of 
authentication must be A or B or C.  Others say: You must authenticate 
using D and E.  Restricting both kinds of content models simultaneously 
is what's not working.

The idea behind having these classess is that you can measure the 
validity of conformance to a class.  Liberty didn't say anything about 
how to do this.  We in the SSTC chose XSD as the formalism for 
expressing this.  Validating a provided instance of a class should allow 
you to determine acceptability of the chosen form of authentication.

The XSD redefine technique has been a boon for this approach.  Ideally 
we would use a repeatable optional choice as the base, and sequences as 
the derived type; this is allowed in XSD but most of the tools don't 
accept it.

(XSD geeks can go here for more info: 
http://www.w3.org/TR/xmlschema-1/#coss-particle)

One idea is to decide the XSD formalism isn't working and go back to 
more of a prose approach.  Another is to define just a flat element 
"library" at the top level, and do more work in the class schemas to 
pull in those elements but define other superstructures individually.

The two-factor classes are the interesting ones because they need to 
supply a set of two methods.  There's a total of three "patterns" that 
need to be satisfied; Scott is planning to split up the top-level 
constructs to match these three, and plans to do this over the next week 
or so during the third public review.

Last week's interop (Scott):

The bearer issue was the most serious that came up; it just needs a 
prose clarification.

NameIDFormat had one problem; there was a mismatch between an earlier 
schema change and the corresponding text.  This also needs a prose 
clarification to explain the semantics of the Unspecified format in the 
presence of a required NameIDFormat.

The use of NameQualifier attributes in the name ID management protocol 
also needed cleaning up.

"Directionality" of federation came up some months ago and was still a 
point of confusion, even though the spec is reasonably clear about this.

A question also came up regarding the intention behind the uniqueness 
property of indexing in metadata.  Are they unique across common 
bindings?  No, it's supposed to be unique with a single role.  The spec 
is mostly clear and needs a tiny bit of extra explanation.

Several issues had to do with relay state, for example the use of 
deflate with signing and whether you URL encode the relay state.

Some other issues had to do with naive implementations of signing; 
mostly the fix for this would be implementation guidelines, but we can 
add a little bit of text to the binding spec saying "don't do this".

None of these have been incorporated yet.

AI: Scott to put together a bulleted list of the already-identified 
issues from the interop to be included in the public review notice. 
(Also send an accounting of these issues to the SSTC list?)

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com