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] | [Elist Home]


Subject: Minutes of 8 May 2001 Focus subcommittee telecon


PLEASE SEND to Eve and Hal the issues that you would like to discuss in 
next week's Focus telecon!

PLEASE CHECK the ACTION items below and do your actions!

PLEASE READ the security-services list and respond to postings!

Attendance
==========
Hal Lockhart
Fred Moses
Bob Griffin
Gil Pilz
Steve Anderson		
Mark Griesi
Michael Lyons
Eve Maler
Zahid Ahmed
Gavenraj Sodhi
Dave Orchard
Marlena Erdos
Bob Morgan
Phill Hallam-Baker
Tim Moses
Carlisle Adams
Jeff Hodges
Stephen Farrell
Ron Williams
Prateek Mishra

Running list of ACTION items
============================
ACTION: Heather Hinton to post 1 May 2001 telecon attendance as a
followup to the meeting minutes. DONE.

ACTION: Bob Blakley to develop and circulate a Word template for all
specification contributors to use.

ACTION: Bob Blakley to work with Phill Hallam-Baker to develop the
simplified architectural model and coordinate it with the proposed
Core Assertions design.

ACTION: Bob Griffin to attempt to map the proposed Core Assertions
design to our requirements.  To be done by the end of the week.

ACTION: Hal Lockhart to publish a fresh issues list.  To be done by the end 
of the day, hopefully.

ACTION: Hal Lockhart and Dave Orchard to update the Architectural
chapter to reflect F2F #2 decisions.  Hal to update his picture 
today.  Dave O to update whole chapter by end of this week.

ACTION: Jeff Hodges to update the Glossary to reflect F2F #2 decisions.  To 
be done by end of week.

ACTION: Darren Platt to update the requirements document to reflect F2F
#2 decisions and publish as a consensus draft ASAP.

ACTION: Dave O to provide more information on the system (other than
DCE) that the "blank form/template" idea is similar to.  DONE.  Dave 
submitted a writeup on the query question.

ACTION: Tim M to produce strawman proposal on doing away with decision
assertions and just using status codes.  DONE.

Issues to discuss this time
===========================
- AuthZ Decision Assertions

   Defer to specific design proposals.

- NoPassThruAuthnImpactsPEP2PDP

   If you bundle a credentials collector and PEP, interoperability is
   compromised as a result of our choice not to cover credentials in
   SAML.  But this is only one of several configurations, and puts a
   focus on password mechanisms in favor of client certs.  It probably
   doesn't make sense to bake extensibility into our current assertions
   for this, because it probably wants to be a whole different kind of
   assertion, so using the "session approach" in this case won't work.

   Tentative definition of "challenge-response": Any authentication
   sequence that takes more than one round trip.

   Radius includes some challenge-response protocols, but not all of them.

RECOMMENDATION: We recommend that the TC authorize a subgroup/task force to 
evaluate a suitable pass-through authN solution for eventual inclusion in 
V.next of SAML.  If the TC likes the design once it is presented, it may 
choose to open up its scope to once again include pass-through authN in 
V1.0.  Stephen is willing to champion this.

- XMLAssertionGenerality

ACTION: Eve to send out pointers to XML Schema tutorials.

   Eve gave a brief oral explanation of XML Schema and its "invisible
   type hierarchy."  We discussed whether to type assertions
   (<attribute-assertion> instead of <assertion>, for example) or
   their "leaf nodes" (a single kind of <assertion> element with a
   <claims> section that will allow a series of individually typed
   object elements).

   Arguments in favor of top-typing:

   - Clarity of typing earliest in a SAML message, to simplify processing;
     and you make explicitly the semantics of our domain model.

   Arguments in favor of bottom-typing:

   - Maximum flexibility; you can mix and match everything from our palette.

   We attempted to do a Quaker poll on these options, but concluded that
   we need to see how the current proposed design matches up to the
   use-case flows first (which Bob Griffin is doing).  We will defer
   more discussion until that time.

   However, in the past we've said that assertions shouldn't need to
   be dependent on the protocol.  And Dave O at F2F #2 brought up the
   idea that "assertions alone" might be a useful conformance level.

ACTION: Phill to produce an update of the assertion draft by Friday.

- OptionalSigAndEncryption

   We agree that these should remain optional.  "None" is a no-starter!
   "Mandatory" is also a no-starter: signing is expensive, and two-way
   SSL connections (e.g.) provide some contexts where signing is not
   helpful.

RECOMMENDATION: Direct the editor of the requirements document to indicate 
that we desire a design where signatures and encryption are optional.

   We noted that we have a "design principle" that we will never point
   to unstable specifications.

Next meeting
============
15 May, noon-2pm ET: TC telecon (first hour), Focus telecon (second 
hour).  Call (800) 377-5653 and ask for the "OASIS teleconference."  Marc 
Chanliau is the host.
--
Eve Maler                                             +1 781 442 3190
Sun Microsystems XML Technology Development  eve.maler @ east.sun.com



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


Powered by eList eXpress LLC