[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for Telecon, Tuesday 9 December 2003
Minutes for SSTC Telecon, Tuesday 9 December 2003
Dial in info: +1 865 673 3239 #238-3466
Minutes taken by Steve Anderson
======================================================================
Summary
======================================================================
Votes:
- Minutes from 25 November 2003 call accepted
- Hold next F2F on Tues-Thurs (2/3-2/5) at BEA
Previous Action Items Still Open:
- [none closed during call]
New Action Items:
- Chairs to solicit info on usage of AuthZDecision/Query
======================================================================
Raw Notes
======================================================================
>
> Agenda:
>
> 1. Roll call
>
- Attendance attached to bottom of these minutes
- Quorum achieved
>
> 2. Accept minutes from previous meeting, 25 November
> < http://lists.oasis-open.org/archives/security-services/
> 200311/msg00169.html >
>
- [VOTE] unanimous consent, accepted
>
> 3. Finalize dates for Boston F2F (week of February 2)
>
- Rob: hadn't checked latest ballot today
- if you haven't voted, please do so
- Eve: can we vote based on whatever trend is appearing?
- Hal: am I hosting?
- Rob: 40% pref for Tues-Thurs, 30% pref for Wed-Fri
- [MOTION] Hold next F2F on Tues-Thurs (2/3-2/5) at BEA
- Rebekah: won't be able to travel then, hoping for dial-in access
- Emily: ditto
- [VOTE] unanimous consent
>
> 4. RSA2004 SAML 1.1 InterOp Next Steps
> < http://lists.oasis-open.org/archives/security-services/
> 200312/msg00036.html >
>
- Rob: has been working behind scenes on space on showfloor, with
curtain for isolation while testing
- if you haven't sent marketing contacts, please do so
- expects to have more info posted on list soon
- not a lot of time to get all planning done
>
> 5. Use-Case Scope Finalization
>
> Note that latest scope document is available from:
>
> http://www.oasis-open.org/apps/org/workgroup/security/download.php/4434/sstc-saml-scope-2.0-draft-11.pdf
>
> We will go through those work items that have been identified as
> requiring use-case scoping, re-affirm ownership and vote if needed.
>
- Prateek: we've tried to identify where there are choices
- in some cases, we also need owners
- there are 3 with choices that will need more formal vote
>
> W-1: Session Support
>
> Vote or achieve consensus on functionality as described in
>
> http://lists.oasis-open.org/archives/security-services/200312/msg00038.html
>
> P1: SAML AA (authentication authority) creates and maintains session
>
> P2: Mechanism to propagate session identifier from AA to SP
>
> P3: Request-Response Protocol for Logout
>
> P4: Idle-timeout protocol based on AA polling SP's about user-activity
>
> P5: Static timeout notification: AA indicates to SP SessionTimeout and
> SessionIdleTimeout values
>
- Prateek: John completed his AI to make fairly structured proposal
- layers of functionality
- sees 5 proposals, P1-P5
- Question is whether we are satisfied with some subset of this (e.g.
P1-P3 looks like ID-FF proposal) or whether we want to include P4 & P5
- MikeB: we were once talking about a session authority, but looks like
now the authentication authority handles it
- John: yes, written as session authority being just a function of AA
- MikeB: ok with that
- RLBob: not precluding dividing it up either
- Hal: but if you imagine them as separate, you have to define msg
exchanges between them
- John: right
- Hal: so that means we are not defining a way for them to be separate,
which seems limiting
- Rob: so then P1 does not support what RLBob wants?
- RLBob: in favor of defining that interface so they can be separate
- Hal: doesn't think there would be that much to do, probably just one
message
- ??: if you truly separate them, you'll need more than one
- MikeB: if you have separate session authority, can you have 1-many,
many-1 or many-many relationships with AAs?
- Rob: was also wondering if AA would interact directly with SA, or
would the contact go through the browser?
- ??: who among us would implement them separately?
- Hal: doesn't think it would be much more work, and to not do it would
be limiting
- John: observed that the reason you have a session is because you are
authenticated
- Tony: we will have them separate
- [more discussion]
- Prateek: how do we proceed?
- MikeB: doesn't think we have agreement on definitions
- Hal: have we agreed to handle idle timeout? if not, doesn't think we
need an authority
- every node will enforce policy, so don't need authority for other
functions
- MikeB: we need idle timeout, but we also need feasible work done
- not against having an integrated AA/SA
- John: if we have separate SA, was planning a SessionQuery and
SessionStatement
- Hal: thinks he can propose a solution to this if we agree on
requirements
- Prateek: proposes three approaches to choose from
- P1-P5
- just P1-P3 (basically ID-FF)
- P1-P5 with notion of separate session authority
- indications are that P1-P3 are not sufficient
- indications are that SA needs to separable from AA
- Tony: would like to see some scoping put on this separation
- Hal: suggests we adopt P1-P5 with notion of separate SA, and later
after we get into design, if we find that it introduces substantial
work, fall back to integrated AA/SA
- ??: regarding scoping, would prefer to optimize for case when they
are co-located
- [CONSENSUS] Accept P1-P5, with notion of separable
session/authentication authorities, but possibility of retreating
to co-located authorities
- [ACTION] Hal to suggest message flows for separate session/authN
authorities, and John, MikeB & Conor to review
- MikeB: would be helpful to understand the purpose of each of the
three components (AA/SA/SP)
- John: requests members to review details of previously-submitted
proposal
>
> W-2: Identity Federation
>
> Accept use-case as described in scope document
>
- [CONSENSUS] no objections
>
> W-2a: SSO with attribute exchange
>
> Accept use-case as described in scope document
>
- [CONSENSUS] no objections
>
> W-3: Metadata and Exchange Protocol
>
> Accept use-case as described in scope document
>
- [CONSENSUS] no objections
>
> W-5: SSO Profile Enhancements - Use Case is flow from SP to IdP
>
> Accept use-case as described in scope document
>
- [CONSENSUS] no objections
>
> W-5a: LECP Profile
>
> Accept use-case as described in scope document
>
- [CONSENSUS] no objections
>
> W-5b: SOAP Client Profile
>
> Accept use-case as described in scope document
>
> NOTE: We need an owner for this work item
>
- Jeff volunteers to own
- [CONSENSUS] no objections
>
> W-6: Proxied SSO
>
> Accept use-case as described in
>
> http://lists.oasis-open.org/archives/security-services/200312/msg00001.html
>
> (missing from scope document)
>
- [CONSENSUS] no objections
>
> W-7: Discovery Protocol
>
> Accept use-case as described in scope document
>
- [CONSENSUS] no objections
>
> W-8: Authentication Context
>
> Accept use-case as described in scope document
>
- [CONSENSUS] no objections
>
> W-9: XML Encryption
>
> Accept use-case as described in
>
> http://lists.oasis-open.org/archives/security-services/200311/msg00116.html
> http://lists.oasis-open.org/archives/security-services/200312/msg00039.html
>
> (missing from scope document)
>
- Hal: two issues for debate
- do we need to encrypt requests/responses?
- didn't imagine need, but someone responded with a use case
- if we think this is needed, not opposed to it
- Scott: we don't support intermediaries in our protocols, so
we can just use transport security
- MikeB: has cases where SSN is used as account id, so could
be a privacy issue
- Scott: not a question of whether we should protect it, but
rather how (SAML level vs. transport level)
- Hal: we have a SOAP binding, so we have to consider SOAP
intermediaries
- thinks it's simpler just to allow for encryption of requests
and responses
- is schema validity a requirement?
- Scott: not sure that it is feasible in all cases
- Scott: believes we only need to clarify our SOAP binding to
allow for XML encryption
- can be lumped in with above issue
- [CONSENSUS] We want to allow for encrypting requests & responses, and
provide schema validity selectively on a usecase by usecase basis
- Eve: if you want to encrypt more, you're on your own
>
> W-15: Delegation and Intermediaries
>
> Accept use-case as described in
>
> http://lists.oasis-open.org/archives/security-services/200312/msg00004.html
> http://lists.oasis-open.org/archives/security-services/200312/msg00035.html
> http://lists.oasis-open.org/archives/security-services/200312/msg00040.html
> http://lists.oasis-open.org/archives/security-services/200312/msg00041.html
>
> (missing from scope document)
>
- Prateek: challenge here is to understand what we are accepting
- is it a case of ensuring that assertions that are delivered by
whatever profile are forwardable?
- Scott: probably not that simple, but that may meet some of the
usecases
- privacy issues might keep that from meeting other usecases
- [more discussion]
- not clear that a "delegation authority" is needed
- [CONSENSUS] Accept usecase, with additional exploration into existing
proposed profiles, with view to the assertions being communicated
further to a backend system -- what are the security considerations
and changes necessary
>
> W-17: Credential Collector Proposal
>
> Accept use-case as described in scope document
>
- [CONSENSUS] no objections
>
> W-19: HTTP-based Assertion Referencing
>
> Accept use-case as described in scope document
>
- [CONSENSUS] no objections
>
> W-21: Baseline Attribute Namespaces
>
> There are two choices here:
>
> P1: Restrict to X500/LDAP attribute names and types as described in
> draft-morgan-SAML-attr-500
>
> P2: Extend to include attribute names relevant to database, UDDI etc.
>
> (scope document describes both of the use-cases)
>
- RLBob: sent msg to list at beginning of this call related to this
< http://lists.oasis-open.org/archives/security-services/
200312/msg00052.html >
- Prateek: how much interest is there in P2?
- Prateek: proposes we accept P1, but not P2
- P1 is adequate, and doesn't rule out other expansions
- Scott: we don't want to be in position where anytime anyone adds a
new X.500 attribute, we have to do something
- [CONSENSUS] Accept P1
>
> W-25: Kerberized Web Browser Profile
>
> Accept use-case as described in Section 3.2 of draft-sstc-use-kerberos
>
- [CONSENSUS] no objections
>
> W-28a2: Reconcile existing attribute usage with XACML
>
> Accept use-case as described in scope document
>
- [CONSENSUS] no objections
>
> W-28d: Issuer Name Enhancement
>
> Accept use-case as described in scope document
>
- [CONSENSUS] no objections
>
> 6. Open Action Items
>
> #0096: Find an owner for W28a1: Existing attribute Usage Codification
> Owner:
> Status: Open
> Assigned: 08 Dec 2003
> Due: ---
> Comments:
>
- Prateek: there are four messages for reference (will add links later)
- Rob: can own, but won't get to it until January
>
> #0093: Discovery Protocol Solution Proposal
> Owner: Scott Cantor
> Status: Open
> Assigned: 23 Nov 2003
> Due: ---
> Comments:
> Prateek Mishra 2003-11-24 04:36 GMT
> AI: Scott Cantor: AI is to take relevant spec from Liberty and produce draft
> proposal
>
- [not discussed on call]
>
> #0088: Understanding ID-FF AuthNContext Elements
> Owner: Scott Cantor
> Status: Open
> Assigned: 23 Nov 2003
> Due: ---
> Comments:
> Prateek Mishra 2003-11-24 03:56 GMT
> Scott will find someone who understands ID-FF AuthNContext work to explicate
> difference between statementRef and class.
> Ref is reallife URI that implies context. Class notion is some sort of
> higher order
>
- [not discussed on call]
>
> #0087: UCs for Making Assertions about Issuers of Assertions
> Owner: Irving Reid
> Status: Open
> Assigned: 23 Nov 2003
> Due: ---
> Comments:
> Prateek Mishra 2003-11-24 03:51 GMT
> ACTION: Scott, Bob, and Irving will develop UCs for Making Assertions about
> Issuers of Assertions
>
> Prateek Mishra 2003-12-08 22:25 GMT
> Scott has published a note on this issue:
>
> http://lists.oasis-open.org/archives/security-services/200310/msg00213.html
>
> Bob and Irving will comment.
>
- [not discussed on call]
>
> #0086: Non-HTTP use-cases related to the LECP profile
> Owner: Bob Morgan
> Status: Open
> Assigned: 23 Nov 2003
> Due: ---
> Comments:
> Prateek Mishra 2003-11-24 03:27 GMT
> ACTION: Bob Morgan - more use cases. More generic use cases, may be not
> involving HTTP. May involve web dav.
>
- [not discussed on call]
>
> #0084: Reconcile terminology in glossary and current use-case document
> Owner: John Kemp
> Status: Open
> Assigned: 23 Nov 2003
> Due: ---
> Comments:
> Prateek Mishra 2003-11-24 03:19 GMT
> Terminology used in sstc-saml-2.0-issues-draft-01.pdf is not consistent with
> terminology found in the current SAML glossary.
>
- [not discussed on call]
>
> 7. Any other business
>
- Prateek: solution proposals due 20 Jan (from last call's minutes)
- reminder that we have focus group call next week
- Eve: can we establish pattern for call agendas?
- e.g., 2 work items per week
- Frederick: how do focus group calls affect membership?
- Prateek: not formal meetings, so no membership impact
- NameIdentifier & Metadata solution proposals will be discussed at
next week's focus group
- Dec 23 TC formal call replaced with focus group call
- Hal: did we gather info on AuthZDecision/Query usage?
- Rob: no, need to make that an AI
- [ACTION] Chairs to solicit info on usage of AuthZDecision/Query
>
> 8. Adjourn
>
- Adjourned
- Next formal TC call will be 6 Dec
- Focus group calls will be held 16, 23 & 30 Dec
----------------------------------------------------------------------
Attendance of Voting Members:
Hal Lockhart BEA
Gavenraj Sodhi Computer Associates
John Hughes Entegrity Solutions
Jason Rouault HP
Paula Austel IBM
Maryann Hondo IBM
Michael McIntosh IBM
Anthony Nadalin IBM
Scott Cantor Individual
Bob Morgan Individual
Greg Whitehead Individual
Rebekah Lepro NASA
Prateek Mishra Netegrity
Conor Cahill Netscape/AOL
Peter Davis Neustar
Frederick Hirsch Nokia
Senthil Sengodan Nokia
Timo Skytta Nokia
Charles Knouse Oblix
Steve Anderson OpenNetwork
Jim Lien RSA
John Linn RSA Security
Rob Philpott RSA Security
Jahan Moreh Sigaba
Jeff Hodges Sun
Eve Maler Sun
Emily Xu Sun
Mike Beach The Boeing Company
Attendance of Observers or Prospective Members:
John Kemp Individual
Frank Siebenlist Argonne Natl Lab
Von Welch NCSA
Tim Alsop CyberSafe
Paul Madsen Entrust
Mike White Individual
Membership Status Changes:
John Kemp Individual - Granted voting status after 12/9/2003 call
Von Welch Argonne Natl Lab - Requested membership 12/2/2003
Tim Alsop CyberSafe - Requested membership 12/4/2003
Ken Woods Sun - Requested membership 12/5/2003
Paul Madsen Entrust - Requested membership 12/9/2003
Bhavna Bhatnagar Sun - Lost voting status after 12/9/2003 call
Ronald Jacobson CA - Lost prospective status after 12/9/2003 call
Bill Howard Vodafone - Lost prospective status after 12/9/2003 call
--
Steve Anderson
OpenNetwork
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]