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: revised minutes from SSTC conference call 2004-03-16

Revised, noting the proper John for one comment, and the attendance of
Rick Randall.

 - RL "Bob"

---------- Forwarded message ----------
Date: Tue, 16 Mar 2004 23:20:20 -0800 (PST)
From: RL 'Bob' Morgan <rlmorgan@washington.edu>
To: OASIS Security Services TC <security-services@lists.oasis-open.org>
Subject: minutes from SSTC conference call 2004-03-16

Minutes for OASIS SSTC conference call, 2004-03-16

Attendance of Voting Members:

Hal Lockhart  BEA
Rick Randall  Booz Allen Hamilton
Gavenraj Sodhi  Computer Associates
Tim Alsop  CyberSafe
John Hughes  Entegrity Solutions
Miguel Pallares  Ericsson
Irving Reid  HP
Paula Austel  IBM
Maryann Hondo  IBM
Michael McIntosh  IBM
Anthony Nadalin  IBM
Scott Cantor  Individual
RL "Bob" Morgan  Individual
Greg Whitehead  Trustgenix
Prateek Mishra  Netegrity
Conor Cahill  Netscape/AOL
Peter Davis  Neustar
Frederick Hirsch  Nokia
John Kemp  Nokia
Charles Knouse  Oblix
John Linn  RSA Security
Rob Philpott  RSA Security
Jahan Moreh  Sigaba
Bhavna Bhatnagar  Sun
Jeff Hodges  Sun
Ron Monzillo  Sun
Emily Xu  Sun

Attendance of Prospective Members or Observers:

Nicholas Sauriol  Nortel
Tim Moses  Entrust



no motions

apparent consensus on details of assertion-level subject issue:
  make it optional,
  permit subjectless assertions/statements,
  don't support mixing subjectless and subjectful statements in
    one assertion,
  don't use schema to enforce restrictions

new issue:  use/description of "subjectLocality" element of Authentication
  Statement needs clarification

new AI:  Prateek and Maryann to draft response to IBM SAML-attacks paper

liaison:  Peter Davis will be liaison with XRI and XDI TCs


attendance taken, quorum achieved

agenda bashing
Hal:  will say something about ITU meeting
Prateek:  item about distinction between SSO and federation establishment

minutes from 2004-03-02 con call accepted by unanimous consent

F2F in Austin:
attendance ballot left open until next week
please vote, Tony needs final account to get badges made

RobP:  outstanding work items?  were all closed after focus call?
Hal:  need help on encryption schema
Scott:  small items re introduction protocol remain ...

discussion items:

issue:  attribute alignment with SPML?
Pr:  request to align from someone
BobM:  descriptor strings are a problem due to lack of registration
  SAML 2.0 will recommend urn:oid approach to attribute naming
    as well as clarifying use of namespace
RobP:  so no changes

issue:  subject at assertion level
Scott:  open question is status of assertions that have no Subjects in the
  traditional SAML sense
  XACML has some use cases
  TC seems to accept this requirement
    but how to do this without reintroducing complication
  doing this with xsd seems to introduce much complexity
Irving:  strongly reject idea that assertions should contain both
  subject-ful statements and non-subject statements
  but generally support idea of
RonM:  is subjectConf bound to Subject?
  is there not a way to "confirm" a subject-less statement?
Scott:  if you want to do confirmation-like things
  you can use SAML conditions
Hal:  his XACML use cases don't require "confirmation"
RonM:  case of "capability" (eg "$100 off list price")
  that may require "proof of ability to use"
  wouldn't confirmation apply?
Irving:  could use anonymized subject ...
Scott:  seems to be consensus on not carrying subject and non-subject
  statements in same assertion
  would like to *not* have new Assertion element
Irving:  Eve has been main one arguing for use of xsd enforcement
  but is not here to argue
  he argues for simplicity ...
Scott:  we argue about what "xsi type" means, what it can constrain
GregW:  win of factoring out Subject is so great, little else matters
Scott:  so problem is how to permit subjectless, but not permit them to be
  mixed in same assertion
  propose two different hierarchies
Irving:  why should subjectless statement users have to reinvent our
  statement types?
  so support just making Subject optional
Greg:  hard to imagine dangerously ambiguous situation,
  statement either needs external subject or it doesn't
RobP:  so is there consensus on optional Subject, no schema enforcement?
Scott:  does this imply defining semantics of subjectless versions
  of existing statements such as Attribute?
Irving:  this is up to profiles to define ...
Hal:  some XACML policies don't refer to "system entities" as subjects
  at all
RonM:  Irving, are all subject confirmations just conditions?
Irving:  no, subject confirmations say a little more
several:  [discussion of subjectless XACML policies]
RonM:  so can there just be subject confirmation and no subject id?
Irving:  yes, that's fine, schema supports it, it's well-defined
Scott:  don't need to throw in URI to say "this space left blank"
JohnK:  is there issue with relationship of subjectLocality and
  these conditions?
Scott:  subjectLocality is widely misunderstood ...
[issue: remaining open issue clarifying use of subjectLocality]

issue:  glossary definition of "federated identity" etc
Pr:  current text refers to "account linking" but not federation
  and accounts seem to be at a different level
  PaulM commented that attribute-based federation needs to be covered
  definition of "identity federation" remains to be done
JeffH:  I'll do one
Irving:  the looser the definition, the better
someone:  it's just a glossary, not normative
Pr:  want to distinguish between simple authentication and
  federation establishment

item:  Kerberos and authn methods
JohnH:  new Kerb doc produced, comment invited
Pr:  could discuss on next week's focus call
JohnH:  John Linn noted that there's duplication of other profiles
  so harmonization of text with other docs needed

item:  liaison with XRI Data Interchange
Hal:  we need to sell that group on SAML approach
Peter Davis:  he will act as liaison with XRI and XDI

recent doc postings:

encryption document:
Hal:  hoping for help on schema
  need to do for attribute what has been done for nameidentifier
Scott:  will try to help ...
Hal:  does anyone see any need to constrain use of XML encryption?
  current text permits anything XML-enc can do
Scott:  seems like conformance text will need to say something
Hal:  XML-enc specifies mandatory-to-implement
Scott:  maybe want to say something about encryption of protocol messages
  in "front-channel bindings"
Hal:  some discussion of this in the doc

metadata document:
Jahan:  metadata schema has been published, need prose written around it

attribute proposal:
RobP:  can't discuss attribute proposal without Eve ...

bindings document:
Scott:  artifact binding tries to answer question of what "InResponseTo"
  is set to
  need to clean up terminology, maybe change name of "artifact"?
    since their definition is changing?
GregW:  why isn't artifact just URL?
  answer:  so size will be constrained, well-known
RobP:  handle on next focus call

core document:
Scott:  only change in this round was Artifact stuff

technical overview document:
JohnH:  problems with terminology mix of 1.x and 2.0
  supposed to be outreach document, not standards track
  so hoping to remove "draft" label

new item:  ITU status
Hal:  attended ITU-T SG17 meetings in Geneva
  three "questions" met
  Karl Best talked about OASIS in general
  Hal talked about SAML and XACML
  they continue to meet, will propose something to OASIS
    so more about this at F2F
  "communications security" group seems to be main one
    but SAML/XACML submission is too new for them ...
  ASN.1 group has ASN.1 representation of SAML/XACML schema
    would our TC be interested in taking this as work item?
    if ASN.1 folks came to TC to do the work?
  most likely 2.0 versions will be submitted to ITU
    for consideration as ITU standards at some point

new issue:  SSO vs federation establishment and maintenance
Pr:  suggest making separation clear
  primarily an issue for conformance, so can conform to each separately

item:  questions about IBM-Zurich attacks-on-SAML paper
  what is TC's response to these, since many have seen it and ask
    if they should worry about these attacks?
Scott:  much of recommendation is "use SSL", and we do recommend its use
  but can't make it a "MUST"
RobP:  how about a response note that can be referred to?
  Prateek and MaryannH will work on proposed doc

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