OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Minutes for Telecon, Tuesday 27 April 2004


Minutes for SSTC Telecon, Tuesday 27 April 2004
Dial in info: +1 865 673 6950 #351-8396
Minutes taken by Steve Anderson

======================================================================
                              Summary
======================================================================

  Votes:
  
    - Minutes from 13 April 2004 call accepted
    - We continue to develop protocol schema and assertion schema
      in lock-step, not allowing version skew between them
  
  New Action Items:
  
    - Scott to propose a profile that standardizes his use case
      related to CORE-11
    - Scott to propose language for CORE-19
    - JohnK to incorporate "Detail" name frag into AuthnContext
      stuff
    - Eve to write wording for versioning section for TECH-2
    - Jeff to review Liberty Trust Guidelines doc for content to 
      disperse thru SAML doc set
    
======================================================================
                             Raw Notes
======================================================================

> 
> Agenda:
> 
> 1. Roll call
>

- Attendance attached to bottom of these minutes
- Quorum achieved

> 
> 2. Accept minutes from previous meeting, 13 April
>    < http://lists.oasis-open.org/archives/security-services/
>      200404/msg00057.html >
>

- [VOTE] unanimous consent, accepted

> 
> 3. F2F Meeting Ballots have closed
>
>    I can attend during the week of 07-June  13  
>    I can attend during the week of 14-June  13  
>
>    With Toronto leading.
> 
> 4. F2F Proposed dates
>
>    Monday,    June 14, 10:00-5:00
>    Tuesday,   June 15, 9:00-5:00
>    Wednesday, June 16, 9:00-2:00
>
>    HP/Irving Reid to host in Toronto, Ontario, Canada
>

- Prateek: tie between weeks of 7 June and 14 June
- chairs have chosen week of 14 June
- Irving: throws a wrench
    - just found out that he is expected to be elsewhere
    - SSTC takes precedence, but if this can move, it would help
    - Prateek: some other critical folks can't attend 7 June
    - so, need to keep plan of 14 June
- Hal: surprised at Monday start
    - Irving: from east coast, can get in morning of
    - can get home in PM of last day, for either coast
- Irving: can start 15 June, but must leave Thurs PM
	- Rob: does Mon vs Tues start affect Irving's other meeting?
    - Irving: no
- Scott: could do Mon-Wed of week of 7 June
	- others have conflicts, though
- Prateek: date set for 15-17 June (start early Tues, end early Thurs)

>
> 5. 
>
>    (a) proposal concerning attributes in core text and relationship
>    to SAML Attribute Profiles document:
>    
>    
>    	(1) The SAML Core document retain a fairly high-level approach
>       towards
>    	<samlp:AttributeQuery> and <saml:AttributeDesignator> elements. In
>    	particular, it should not specify elements/attributes/values which
>    are 	of interest only to particular communities. 
>    
>    	We would retain URI-based attribute naming within core and
>    	also include language explaining how to determine
>    	identity of <attributedesignators> for this case
>    
>    
>    	This would also mean removal of <samlp:Resource> 
>    
>    	(2) Guidance on creating specific attribute profiles be provided in
>    a
>    	separate document (A first cut is available in the most recent draft
>    of 	the Attribute Profiles for SAML 2.0,
>    	draft-hughes-mishra-baseline-attributes-03.pdf). This would include
>    the
>    	naming profiles (ValueType attribute), any additional XML attributes
>    defined 	by the profile, syntax for attribute names, rules for
>    determining equality of attribute designators.
>    
>    	(3) Specific attribute profiles of interest to the SAML community be
>    added
>    	to the document. The current document includes definitions of a
>    X.500/LDAP and DCE UUID profile. 
>    

- Eve: what does it mean for core to be generic?
    - continuing in the way it is generic now?
    - Prateek: yes
    - had proposals for adding certain attributes into core, but this would
      move those out into profile, with a guideline doc
- Eve: other than use of term "profile" for this, it seems unobjectionable
    - seems like we need to determine what is a profile vs extension, and
      how it affects conformance
    - RLBob: also talked in focus call about including profiles in 
      metadata to express support
    - Prateek: Eve, any other term than profile?
    - Eve: namespace won't do
    - RLBob: IETF has "domain of interpretation", but won't suggest it here
    - Jeff: could use that in definition
    - no suitable alternative
- Prateek: <samlp:Resource> should be defined in the attr profile that 
  uses it, so it would get removed from core
    - sent out msg to saml-dev soliciting feedback on this
- Prateek: sounds like we have consensus around this

>    
>    (b) XACML Attribute Profile Proposal 
>    
>    	We see value in there being a SAML attribute profile that is
>    compatible 	with XACML's needs.  Such a profile would in no way
>    constrain    	application of the more general definition of SAML.
>    
>    	To this end, we make the following proposal: we would develop a
>    profile 	for SAML attributes that are to form input to an XACML
>    decision engine.  
>            Such a profile would be progressed under the procedures of the SAML
>    committee, 
>            but the XACML committee would supply the development effort.  
>            Members of the SAML committee (of course) would be expected to
>    review the profile 
>            from the point of view of consistency with the aims of the SAML
>    committee and to 
>            approve it as one of their products.
>    
>    	There are a number of reasons for proposing this as a SAML (rather
>    than 	an
>    	XACML) work item.  The first is that we want to ensure that the SAML
>    expertise is 
>    	brought to bear on the topic.  The second is that we expect SAML
>    attribute 
>    	designers to seek guidance amongst the documents of the SAML
>    committee, 	rather than 
>    	any other (such as XACML).  The final reason is that
>    	(obviously) we ARE talking about a profile of the SAML spec., not
>    the 	XACML spec..
>    

- Prateek: coincidentally, received this from XACML folks
- Hal: expected this to be a SAML work item
    - idea would be to define a profile that made XACML use very simple
- Conor: why would this be a SAML effort vs. XACML effort?
    - Hal: in large scale environments, people start with SAML, and later
      discover need for XACML, and this raises certain issues with 
      deployers sooner rather than later
    - Prateek: would support this
- Prateek: this is not a new work item, but rather a re-spin of discussions
    - Hal: understood that this would have his name on it to work on
- Eve: wasn't XACML writing a profile of SAML, including how to use attrs?
    - Hal: thinks so
    - Eve: so if we do this, it would be part of XACML profile?
    - Hal: doesn't see distinction
    - Eve: just wants to see relationship to other profiles/extensions
    - Scott: there isn't one
    - can be composable, but beyond that, they're orthogonal
- Prateek: so, status of this doc is that it has some rough edges, and Eve
  will take a pass thru it, and then it will be ready for inclusion
  in doc set

>    
>    (c)  Review of recently published drafts
>    
>     
>    http://www.oasis-open.org/apps/org/workgroup/security/download.php/6527/sstc
>    -saml-authn-context-2.0-draft-04a-diff.sxw
>    

- JohnK: in airport, so can't walk thru doc
	- did add some of the SAML AuthN methods as context classes
	- not done with it, but people can look and see where he's headed
	- factored in the 2 Kerb-based methods as discussed on last call
	- hope to get done next week
- Prateek: so we should start responding to the current changes

>    
>     
>    http://www.oasis-open.org/apps/org/workgroup/security/download.php/6438/sstc
>    -saml-profiles-2.0-draft-06-diff.pdf
>    

- Scott: re-did profiles doc, incorporating lots of feedback
    - replaced older 2 profiles
    - incorporated proposal addressing concerns of use of validity time
      conditions
    - reworked bearer confirmation method
    - hasn't determined where XML schema portion of this should live
- Prateek: we've had this open action re: forwardability of assns
    - we can come back to that after this settles out
    
>    
>    (d) Action Item Review 
>    
>        CONSOLIDATED LIST TO FOLLOW IN THE AM
>

- Prateek: still working on this, hope to publish today, maybe on call

> 
> 6. If possible, I'd like to take advantage of having a quorum to
>    decide the priority-A issues on the issues list:
>
>    http://www.oasis-open.org/committees/download.php/6259/sstc-saml-2.0-issues-draft-08-diff.pdf
>
>    CORE-11 Validity Period of Identifiers
>    CORE-19 Multiple Encryption Keys and Recipient Information
>    CORE-20 Change AuthnContextStatement Element Name
>    BIND-3 Establish a Mandatory Profile
>    TECH-2 Versioning of Elements
>    TECH-3 Impersonation Using SubjectConfirmation and KeyInfo
>
>    I expect that some of these, at least, should be relatively easy to 
>    settle.  We had prioritized them as A's, not necessarily because of 
>    their "degree of difficulty," but because we felt implementers would 
>    need to know their outcome as soon as possible.
>
>    (I also think we should try and knock down the prio-B's on the May 11 
>    call...)
>

- CORE-11
    - RLBob: recalls that agreement was that validity period was in style
      of limits on processing the assn
    - Scott's other work in bearer confirmation dealt with other semantics
    - Prateek: thought this dealt with validity of *encrypted* identifiers
    - Eve: originally was, but had been instructed to delete "encrypted"
    - [more discussion, regarding Scott's use case, which apparently can
      already be handled without further addition]
    - [ACTION] Scott to propose a profile that standardizes his use case
      related to CORE-11
    - as far as Scott is concerned, this issue is closed
    - Prateek: has concern over more generic context
    - there is need for lifetime of persistent identifiers exchanged
      between parties
    - will write up separate msg about this
    - pending Scott's AI, this can be CLOSED
- CORE-19
    - Scott: do we want to say anything about expressing the audience to
      whom you've encrypted the data
    - this wouldn't be expressed via our spec, it would be the Recipient
      attr from XML Encryption
    - analog to our AudienceRestriction
    - [ACTION] Scott to propose language for CORE-19
- CORE-20
    - Eve: "...Statement..." inside a Statement is odd
    - Scott: "Detail"?
    - Eve: sounds good
    - [ACTION] JohnK to incorporate "Detail" name frag into AuthnContext
      stuff
    - CLOSED
- BIND-3
    - Eve: Dan Blum of Burton wanted to increase interop by dictating
      mandatory profiles
    - at recent interop, most everyone did both Artifact & POST
    - leaning toward mandating both
    - Prateek: thinks this stays open until we have an early draft of
      conformance doc
    - remains OPEN    
- TECH-2
    - Eve: came close to declaring this done at F2F
    - discussed that assns are short lived, so their versions shouldn't 
      affect much
    - proposal is that you can't mix versions
    - Prateek: can't think of case where you would need to mix them
    - [MOTION] We continue to develop protocol schema and assertion schema
      in lock-step, not allowing version skew between them
    - amounts to doing nothing different that what we've been doing already
    - could state that in core
    - [ACTION] Eve to write wording for versioning section for TECH-2
    - [VOTE] no objections
- TECH-3
    - Eve: HolderOfKey issue is still open
    - Scott: do we define HolderOfKey if there are no profiles that 
      reference it (same for SenderVouches)?
    - put in language for HolderOfKey saying that subject of assertion 
      should be interpreted to be the holder of the key
    - Irving: getting more uncomfortable with this
    - seems to be strange way to allow delegation for Ron
    - Prateek: is there a proposed change here?
    - Scott: if we're not going to use this anywhere, should we leave it
      or take it out?
    - similar to Anne's argument about XACML accommodations
    - proposal is to remove both HolderOfKey and SenderVouches, and leave
      their definitions to things like WSS SAML Profile
    - current text is in profiles, section 3
    - current position is to go back an review this text further
    - will try to wrap up at next call

> 
> 7. Any other business
>

- Scott: metadata
    - wants to redo schema, based on feedback and playing with it
    - had mechanism where lots of defaults were specified, with overrides
      permitted
    - now not sure that complexity is worth the space savings
    - suggests simplifying
    - Prateek: agrees
    - size not that important
    - Scott: will take a pass at it this week
- Eve: did ValueType get addressed on last call?
    - Prateek: this was lumped into attribute profile proposal
    - would be in separate profile, as core remains generic
    - Eve: if this was the agreement, would like to effect that change in
      next draft
- Eve: wants to double check everyone's understanding of work item status
    - the only items still open are W-2a, W-4, W-9, W-14, W-25, W-27, W-30
    - [ACTION] Jeff to review Liberty Trust Guidelines doc for content to 
      disperse thru SAML doc set
    - closed W-5, W-6, W-7, W-15 here

> 
> 8. Adjourn
>

- Adjourned


----------------------------------------------------------------------

Attendance of Voting Members:

  Hal Lockhart BEA
  Gavenraj Sodhi Computer Associates
  Irving Reid HP
  Paula Austel IBM
  Maryann Hondo IBM
  Michael McIntosh IBM
  Anthony Nadalin IBM
  Scott Cantor Individual
  Bob Morgan Individual
  Prateek Mishra Netegrity
  Conor Cahill Netscape/AOL
  John Kemp Nokia
  Charles Knouse Oblix
  Steve Anderson OpenNetwork
  Darren Platt Ping Identity
  Jim Lien RSA Security
  John Linn RSA Security
  Rob Philpott RSA Security
  Dipak Chopra SAP
  Jahan Moreh Sigaba
  Bhavna Bhatnagar Sun
  Jeff Hodges Sun
  Eve Maler Sun


Attendance of Observers or Prospective Members:

  Jason Rouault HP
  Rick Randal Booz Allen Hamilton
  Senthil Sengodan Nokia


Membership Status Changes:

  James Vanderbeek Vodafone - Requested membership 4/13/2004
  Rick Randal Booz Allen Hamilton - Requested membership 4/14/2004

--
Steve Anderson
OpenNetwork




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]