[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for 20-July 2004 SSTC con-call (official and focus call)
|
Official meeting minutes compliments of Eve.
Focus call minutes compliments of Eve and Rob. > Agenda for SSTC
Conference Call, July 20, 2004 > > Dial in info: +1 865
673 6950 #351-8396 > >
1. Roll Call Quorum achieved 22/30 members present Conor P.Cahill Hal Lockhart Rick Randall Ronald Jacobson John Hughes Paula Austel Michael McIntosh Anthony Nadalin Scott Cantor Bob Morgan Prateek Mishra John Kemp Jim Lien John Linn Rob Philpott Dipak Chopra Jahan Moreh Jeff Hodges Eve Maler Emily Xu Mike Beach Bhavna Bhatnagar Prospective Members James Vanderbeek Gavenraj Sodhi Ron Monzillo Ari Kermaier Vamsi Mottokurur Peter Davis Nick Ragouzis >
2. Agenda Bashing >
a. Can any of the agenda items be moved to
discussion following > adjournment (i.e.
follow official call with focus call)? We will put everything into
the quorate part of the call. > >
3. Minutes from July 6 conference call are
missing attendance list > –
need to be reposted. This has been done in
message 106: http://lists.oasis-open.org/archives/security-services/200407/msg00106.html APPROVED by unanimous
consent. >
a. >
_http://www.oasis-open.org/archives/security-services/200407/msg00086.html_ >
4. Status of SSTC Last Call review: >
a. Comments from John H: >
i. >
_http://lists.oasis-open.org/archives/security-services/200407/msg00116.html_ > >
ii. Follow-up in msg00117 and 00118 Line 2206 in Profiles (which
also pertains to Core) shows a hanging empty <xsd:sequence>
element. JohnH: It's schema-acceptable, but should we show it? Scott
prefers them and will add throughout. AI: Scott to rationalize
presence of empty <xsd:sequence> elements in empty types in the schemas. >
b. >
i. >
_http://www.oasis-open.org/apps/org/workgroup/security/download.php/7783/sstc-saml-profiles-2.0-draft-16-diff.pdf_
Summary of changes: Some
minor substantive and editorial changes here. Eve reminds editors to make
spec changes during the last-call period visible only to the TC, not
to the public (so that reviewers won't get confused with line numbers
etc.). >
c. >
i. > _http://www.oasis-open.org/apps/org/workgroup/security/download.php/7792/sstc-saml-bindings-2.0-draft-17-diff.pdf_
Summary of changes: Made a
structural/editorial change suggested by Eve and improved the PAOS
material. >
d. Scott posted Profiles draft-17. No
PDF’s posted. .SXW file: >
i. >
_http://www.oasis-open.org/apps/org/workgroup/security/download.php/7806/sstc-saml-profiles-2.0-draft-17.sxw_
Summary of changes: Added
new paragraphs to the single logout profile and made terminology changes
around service provider->session participant. Also
changed the attribute profile at the end; revisited several of the pieces
previously left hanging. Replaced the LDAP processing rules using text
from JeffH. This is covered in the thread that RLBob forwarded to the
mailing list. Split up some profiles. Had an exchange with Anne
Anderson re appropriateness of URI usage for attribute names. AI: Scott add something to
Core around our use of URIs as identifiers in the spec, to explain that
proper use of URIs results in uniqueness. >
5. New issue from Ron on list (re:
AssertionID/WSS Direct reference): >
a. >
_http://lists.oasis-open.org/archives/security-services/200407/msg00076.html_ Ron: There was a lot of
discussion on this, with the conclusion that there's nothing we can do
here. Best to wait until it's possible to do an "ID
unification" with W3C's xml:id construct. Encapsulation (adding a new parent element)
shouldn't be done at the SAML level. Rather than creating another reference
method in STP now, they used the mechanism that's there, which will
work for SAML V1.1. For now, just use key identifier for references. Close this issue with no
action. Scott: The WSS TC conclusion
was a mistake. Prateek: Should the SSTC put
together a formal note on this? Tony: Perhaps Scott should write
this because the WSS TC would love to get this input. Rob: The
SSTC itself doesn't need to take action; Scott and all others are invited to
send thoughts to the WSS TC. Jeff: And of course to join it and take
part if they wish; better than just complaining! >
6. New potential issue from Eve (re: WSDL for
SAML services): >
a. >
_http://lists.oasis-open.org/archives/security-services/200407/msg00102.html_ > >
b. Scott suggests post 2.0? Don't make this a V2.0
deliverable; treat it as a "deferred" issue on the V2.0 issues list, so
that it automatically gets added as a candidate for the next wave of work. AI: Eve to add WSDL creation
to the issues list. >
7. FYI from Peter Davis (re: SAML+SIP profile): >
a. >
_http://lists.oasis-open.org/archives/security-services/200407/msg00107.html_ Peter: There's strong
interest in the SIP community to incorporate new kinds of tokens; SAML was
the first one put out. No changes sought from the SSTC. >
8. List posting from RL “Bob” (re:
X.500/LDAP attribute values): >
a. >
_http://lists.oasis-open.org/archives/security-services/200407/msg00115.html_ This work has now been
incorporated into Profiles. JeffH: It may need more polishing, but it's 90%
there. Prateek: The Conformance
document is in an early draft and isn't part of last call, but it's out
there. Eve: Why not treat it as a "focus" topic this week, then promote it
to "quorate" topic next week? Scott: Will send some comments to the
list. Rob: Note that this document is normative, just not part of
the last call. What about the idea to make the Conformance doc the
official entry point? Eve: Strongly agrees. General agreement. AI: Eve to write up a text
section and a suggested new title for the Conformance document,
reflecting this wider role, and post these to the list. >
9. Issue list review (Eve) AI: Eve to revise the issues
list this week; it appears that all the really significant technical
issues have been closed, but there was issue-numbering confusion
last week. >
10. Action item review (see list below) >
11. Any other business > 12. Adjourn > > Report created 19 July
2004 11:30pm EDT > ***
* > ***#0180*: Need to
update SAML server trust document > ***Owner*: Jeff
Hodges > ***Status*:
Open > ***Assigned*: 12 Jul
2004 > ***Due*:
--- > ***Comments*: > Rob Philpott 2004-07-20
01:59 GMT > Original AI was for Eve
to follow up with Jeff to determine whether he > would be updating this
doc. That was done. > > Discussion of this AI
on 13-Jul indicates that the update will be a post > 2.0 deliverable.
Reassigned AI to Jeff for now. Still open. >
******* * > ***#0179*: Does
conformance meet pki-cross-domain-profile-draft-01.doc >
requirements? > ***Owner*: Rick
Randall > ***Status*:
Open > ***Assigned*: 12 Jul
2004 > ***Due*:
--- > ***Comments*: > Prateek Mishra
2004-07-12 21:47 GMT > CHeck conformance
document to see if it captures the desired > functionality described
in this document. We haven't seen an update to
this. >
******* * > ***#0176*: Provide
sequence diagrams for profiles > > *Owner*: Jeff Hodges > > *Status*: Open > > *Assigned*: 23 Jun 2004 > > *Due*: --- > > *Comments*: > Rob Philpott 2004-06-23
20:14 GMT > as discussed at F2F #5. > > Diagram for BAP sent to
list. Will finish this week. > *#0175*: Add Security
Context to glossary > > *Owner*: Jeff Hodges > > *Status*: Open > > *Assigned*: 23 Jun 2004 > > *Due*: --- > > *Comments*: > Rob Philpott 2004-06-23
20:12 GMT > as discussed at F2F #5 Will finish this week. > *#0172*: need text for
syntax of attr values in LDAP/X.500 profile > > *Owner*: Bob Morgan > > *Status*: Open > > *Assigned*: 23 Jun 2004 > > *Due*: --- > > *Comments*: > Rob Philpott 2004-06-23
20:05 GMT > Discussed at f2f#5: > RLBob to review & propose
text for handling syntax of attr values in > LDAP/X.500 profile. Closed. > *#0166*: Investigate
use of Wiki from teh web site > > *Owner*: Scott Cantor > > *Status*: Open > > *Assigned*: 22 Jun 2004 > > *Due*: --- > > *Comments*: > Rob Philpott 2004-06-22
16:40 GMT > Scott will investigate
the establishment of a wiki for SSTC use to be > linked from the SSTC
web site. Low-prio. In progress. > *#0163*: Need process
for submission of profiles/authn context classes, etc. > > *Owner*: Rob Philpott > > *Status*: Open > > *Assigned*: 22 Jun 2004 > > *Due*: --- > > *Comments*: > Rob Philpott 2004-06-22
16:29 GMT > On the web site, we
need to state what the process is for submitting and > dealing with additional
authn context classes, new profile documents, etc. > > Rob Philpott 2004-06-23
16:03 GMT > Note that this is
different from AI 164 for SCott and John K to propose > text within the spec
documents that points to the web site. Still open. > *#0160*: Separate
Privacy concerns language from Element/Attribute > descriptions > > *Owner*: Prateek Mishra > > *Status*: Open > > *Assigned*: 30 Apr 2004 > > *Due*: --- > > *Comments*: > Prateek Mishra
2004-04-30 18:14 GMT > Jeff H - We need to
highlight privacy considerations related to core, > could be notes in core,
could be section. > *** AI: Prateek - will
generate list potential changes from core Still open. Eve: Note
that the explanation of constraints on session indexes now includes a
rationale along these lines. > *#0158*: Propose
changes to definition of Federation in glossary > > *Owner*: Prateek Mishra > > *Status*: Open > > *Assigned*: 30 Apr 2004 > > *Due*: --- > > *Comments*: Still open. Prateek
will send thoughts to the list. > *#0157*: Define Binding
and Profile in Glossary > > *Owner*: Jeff Hodges > > *Status*: Open > > *Assigned*: 30 Apr 2004 > > *Due*: --- > > *Comments*: > Prateek Mishra
2004-04-30 18:10 GMT > o "atomic unit of
interoperability" proposed In progress. > *#0144*: Explain
optional subject decision > > *Owner*: Eve Maler > > *Status*: Open > > *Assigned*: 29 Apr 2004 > > *Due*: --- > > *Comments*: > Prateek Mishra
2004-04-29 21:51 GMT > *** AI: Eve: Optional
subject implemented in core spec prose. Schema > shows that subject is
optional. > > o Eve: Has wanted to
create a rationale for some of the decisions made > on spec. Decision on
subject less statements is a good example of what > needs to be documented.
Making an explicit design decision that is not > really explicit on. By
choosing to add prose to core spec we're making a > stealth abstract
profile (generic design decision) that applies to all > explicit profiles. > > o Scott: data model
(design) decision to require subjects in all SAML > statements. > > Rob Philpott 2004-07-20
02:05 GMT > 13-Jul con-call minutes
note that the issue should be closed. and that > Eve "may work on
commentary". Eve: The thought here was that
we may have an optional post-V2.1 deliverable that explains
the "XML rationales" for various things. JohnK: But there are
selected places in the actual specs where it would be helpful; he has suggested
these. Eve: Let's treat these comments one by one, then. [Scott drops off.] > *#0132*: Text to
explain privacy reqts when using certain NameFormat values > > *Owner*: John Kemp > > *Status*: Open > > *Assigned*: 13 Apr 2004 > > *Due*: --- > > *Comments*: JohnK: Scott has already
made some attempts to do this in Core; should the AI still exist?
The current text looks okay to him. Let's close this now, but
JohnK recommends that the TC review the language and comment if they
see fit. > *#0125*: Propose
language to explain that AuthNResponse may contain > attribute statements > > *Owner*: Prateek Mishra > > *Status*: Open > > *Assigned*: 16 Feb 2004 > > *Due*: --- > > *Comments*: > Prateek Mishra
2004-02-16 14:46 GMT > Easy to do but needs
proposal on validity of assertion life-times as well. Still open. > *#0123*: Obtain MIME
type registration for HTTP lookup of SAML > > *Owner*: Jeff Hodges > > *Status*: Open > > *Assigned*: 13 Feb 2004 > > *Due*: --- > > *Comments*: > Rob Philpott 2004-06-23
15:29 GMT > Attached is the initial
rev of an I-D seeking to register the MIME media > type >
"application/saml+xml". Please review. > > I've pinged the I-D
editor to request a filename for the doc, I'll > submit it to > both the I-D editor and
the SSTC doc repository once that's finalized (std > procedure for I-Ds). > > In concocting this
draft, I've noted that MIME media type registrations > aren't > necessarily the simple
little registration exercise I'd thought they > were. They > (the
ietf-types@iana.org denizens) may desire more content, e.g. sec > considerations, in this
doc. We'll see. Nominally, I think it's "good > enough" > as is, especially since
the SAML spec sets have thorough sec considerations > sections and I've
referenced said spec sets carefully. Anyway, we'll see. > > Also, I based this on a
draft registration for application/rdf+xml. In that > draft, Aaron Schwartz
claimed an optional parameter of "charset", and > indicated > that the considerations
thereof are the same as for "application/xml" (as > documented in http://www.ietf.org/rfc/rfc3023.txt).
Additionally, he did the > same thing for the
"encoding considerations", i.e. said they were the > same as > for
"application/xml". So, without excrutiating research, I did the same > thing > in this draft.
fwiw/fyi. > > anyway, lemme know
whatcha think. > > thanks, > > JeffH Still open. Other business: John Linn asks that people
review his draft paper in response to Thomas Gross. JeffH thanks
John for his efforts. Eve notes that the draft looks good. AI: Prateek to comment on
the draft by July 23. AI: <someone>
ultimately to provide a formal response to Thomas Gross. (This AI is just to help us
track this, to make sure we do it.) [Emily Xu announces her
presence; noted on the attendance sheet.] Formal meeting adjourns. ------------------------------------------------------------------------ Focus meeting starts: Attending: Prateek, Rob,
Eve, Jeff, JohnK, RLBob, Nick Ragouzis, (did we miss anyone?) The latest Conformance draft
is here: http://www.oasis-open.org/committees/download.php/7582/sstc-saml-conformance-2.0-draft-01.pdf - Prateek: 2 parts to the
discussion: 1) the approach as a whole, and 2) filling in the cells of the
chart. We would like to ensure that we've filled out the matrices
appropriately. - Eve: The term
"categories" for the stuff in Section 3 is not very
descriptive. They're more like feature sets. - JohnK: In - JeffH: Can we just be
happy with "profiles of profiles" as long as we qualify the purpose
of each level, like "conformance profile", "interop
profile", etc.? We can keep refining as we go up. - Nick Ragouzis: In Liberty,
is trying to move to "interoperability profile". - Rob: We've had some discussions about conformance
profiles vs. interop profiles. We don't want to blur the
distinction.Unfortunately, “conformance profiling” doesn’t
ensure “interoperability” It appears that feature set
#3, Enhanced Client, really wants to be named "Enhanced Client SSO",
and there needs to be an additional column for the enhanced client role, since
this is something that a product might want to claim conformance to. We might need roles for the
old SAML V1.1 roles of "attribute authority" etc. We could have
a "SAML responder" role that implements a "feature set"
(that doesn't exist yet) called "attribute query". Do we need
dummy/pass-thru feature sets (conformance profiles) along with dummy/pass-thru
profiles for the obvious protocols? - Prateek: The somewhat
arbitrary piece is the feature sets (rows). - Rob: Instead of
"role" (to avoid the "row"/"role" problem on
telecons), how about "operational mode"? - All: Sounds okay. - Eve: Can we ensure that
the feature sets are "flat"? Prateek: <rant> want to see fewer, more robust
“feature sets” to avoid looking like - Eve: To combine these two
goals, any temptation to add a bunch of new ever-finer ones should be met by an
effort to bundle the features in bigger bunches. Let's avoid - Eve: This means some
implementors will have to implement MTI features they're not intending to use or deploy,
but makes it more attractive and simple to understand (and hopefully adopt)
SAML. Feature
sets: Op mode
1 Op mode 2 ... A B C ... - Rob: So we have columns such as “basic
SP”, “full sp”, “basic idp”, “extended/full
idp”. - Eve: Do feature sets have
differing-enough op modes that we should make one matrix per feature
set? Maybe not. - Eve: Also there are items in the old conformance
doc that don’t appear here (e.g. nesting levels). Need to move them
forward. - AI: Prateek to review the
old Conformance document and pull forward whatever material is
appropriate into the new one. - Prateek: want to make sure that certain
operational modes are available that minimize the number of rows that are MTI. - JohnK: But if don’t encourage the support of
the NameID mgmt protocols then it may create interoperation issues. It’s
all about making the tradeoffs. - AI: Prateek will take the input from the call and
present a new table proposal. - Nick: We still have the question of whether the
NameID mgmt protocols are MTI in basic. What’s the process for
reaching resolution. - Prateek: We should take this to the general SAML
community. - Jeff: Oracle and IBM just went through - Prateek: why is that? Is SAML just meant for the 5
major vendors only? - Jeff: that is a red herring argument. A small
company like PingID implements the features and has passed conformance.
They’re not that big a deal. - Rob: We do not need to continue this argument
here. What we need is to build the proposed matrix and then debate among
the entire TC as to whether we need an operational mode (column) that just does
simple SSO without nameID mgmt etc. Let’s first get the matrix proposal
on the table. Prateek has committed to do that. - All: general agreement - Call adjourned. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]