[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for 14-Dec SSTC focus group con-call
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]