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

Irving      Reid

Paula Austel

Michael     McIntosh

Anthony     Nadalin

Scott Cantor

Bob   Morgan

Prateek     Mishra

Frederick   Hirsch

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     

Forest
Yin  

Carolina
Canales

 

>
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.      Frederick
posted Profiles draft-16. Diff version:

>
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.      Frederick
posted Bindings draft-17. Diff version:

>
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
 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, Irving

(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 Liberty, there are conformance profiles vs.
(regular?) profiles of the protocols.  

- 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 Liberty’s long list of 20+ feature sets
</rant>.  Overall, we should have as few of them as possible and
make them strong.  

 

- 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 Liberty's 22 conformance
profiles.  

- 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 Liberty conformance
testing. This means the argument that minimalist implementations are few and
far between.

 

- 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.