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: [security-services] Minutes for Telecon, Tuesday Feb 05, 2002

Minutes for SSTC Telecon, Tuesday Feb 05, 2002
Dial in info: +1 334 262 0740 #856956
Minutes taken by Steve Anderson

> Main Theme: Issuing Last Call Drafts
> 0) Opening comments

- Joe does not believe we are ready to go into Last Call, which means
  we will likely miss the 1 Mar quarterly submission
- Hal: we could reduce the public review period, since we invented it

> 1) Roll Call

- Attendance attached to bottom of these minutes
- Quorum achieved.

> 2) Discussion of getting to Last Call & hitting 1 Mar deadline
>    submitting to OASIS

- Hal: Motion to reduce the eval & rewritting period of last call
  period to less than 1 week, in order to keep to 1 Mar submission
- Prateek: second
- Hal: wants to avoid missing 1 Mar unless absolutely necessary,
  and sense is that we are tidying up details
- Joe: we delayed last call from last week to this week, but closure
  of issues has not progressed sufficiently
- not trying to relieve pressure to complete, because we are close
- next opportunity to submit to OASIS is 1 June
- Jeff: once we complete last call, we can announce it as a committee
  spec, and just wait for next OASIS submission opportunity (1 June)
- spec would be frozen from that announcement until submitted to OASIS
- RLBob: could we submit to OASIS on, say 1 April, effectively
  freezing it
- yes, but OASIS would not send it out until 1 June
- Joe: status of doc would change to "submitted to OASIS"
- Eve: we could stop these regular meetings and focus on own
- Hal: motion is really to wait a week before deciding to slip the date
- Prateek: doesn't see blocking issues, just lots of details
- Motion: Enter Last Call 1 week from today, 2 week last call
  commentary period, 2 days for eval & incorporation
- [Vote] no objections

> 3) Hal's new list of resolutions moved to DEFERRED
>    < http://lists.oasis-open.org/archives/security-
>      services/200202/msg00020.html >

- Motion to move these to DEFERRED
- [Vote] no objections

> 4) Hal's second email today
>    < http://lists.oasis-open.org/archives/security-
>      services/200202/msg00021.html >

- Hal: doesn't think this can be driven to decision today
- doesn't have strong inclination one way or the other
- Jeff: was trying to solicit reaction from list on these items
- Hal: these are the last three uncertainties, everything else is
  clearly closed, deferred or still open
- Joe: this was informational, and should be voted on next week

> 5) Eve's list of High Priority concerns from Sun
>    < http://lists.oasis-open.org/archives/security-
>      services/200202/msg00012.html >
>    H1. Resource and Decision optionality

- Hal: thinks they should be required
- RLBob: is empty string sufficient?
- Eve: xsd may address this, will check
- Eve: actually, there is a meaning to an empty URI Ref, which is the
  current doc
- Hal: meaningful in SAML?  would requester include actual content
  that it is asking access to?
- Hal: suggests that we agree that "not optional" is our intent, and
  research mechanics in next day or so
- Scott: not sure if facets can be used to eliminate possibility of
  empty string
- RLBob: could just say that empty string is undefined
- Agreed that elements are required
- [Action] Eve to write up recommendation on empty Resource
- Hal: doesn't see problem, his product will try to match blank string
  to policy info, which will produce no matches
- Prateek: wants to avoid possible malicious misinterpretation
- Irving: if we use proposed binary match logic, there should be no
- Scott: Resouce is still optional in attribute query

>     H2. Queries that return multiple assertions and statements

- Resolution: fix the wording so that it no longer suggests only one,
  except in the cases of artifact & assertionID
- Eve: on second half of this item, is it bad to return multiple
  authN statements?
- Prateek: no, want to return info on all authN events
- Eve: what to do with multiple authN statements?
- Hal: depends on policy, which may distinguish based on X509 vs. pwd,
- Hal: Asserting parties speak the truth (as best they know it) and
  relying parties use that as they see fit
- [Action] Prateek to generate changes to doc that broaden language
  to not speak of returning a single statement, and to generate
  additional text for intro

>     H3. Comparison functions of Subject and ConfirmationMethod

- Prateek: referred to email from Stephen Farrell that lays out
  "wildcard" matching rules
- Hal: wants to deprecate the case where name identifier differs from
  info in subject conf (when present)
- Phill: not a good idea, as VeriSign sometimes generates random
  subject name in cert
- Hal: we have separate confirmation method for holder of key, which
  would work
- Irving: would require additional code to disassemble certs
- Prateek: this sounds like a particular profile, where these pieces of
  info must be consistent
- Hal: would settle for clear explanation, because there seems to be
  non-intuitive implications of this "wildcard" matching rule
- Prateek: proposes that we review Stephen Farrell's email:
  < http://lists.oasis-open.org/archives/security-
    services/200202/msg00003.html >
- Prateek: proposes that this is an adequate resolution
- Simon: we are not specifying subject equivalency
- Prateek: correct
- Relevant email from Irving on element comparison
  < http://lists.oasis-open.org/archives/security-
    services/200202/msg00018.html >
- Hal: no objections to Stephen Farrell's matching cases?
- Irving: may need different cases for queries, since queries should
  never give back less than what was given
- no clear objections to this proposal, but not yet reviewed by
- [Action] Prateek to propose normative text

>     H4. SubjectConfirmation potentially obviating authN assertions

- Hal: if Kerberos ticket is used as SubjConf, the information in
  authN assn becomes redundant
- other similar possibilities
- doesn't think it would be useful, but it would also be harmless
- Hal: suggests answer of "that's correct, but not a problem"
- Eve: ok with it, will take back to Sun engineers

>     H5. ConfirmationMethod vs. AuthenticationMethod

- Hal: clarification
    - AuthN assn is a report about a past act of authenication
    - SubjConf is a way of determining/proving who current entity is
    - mechanisms can be the same, but intent is different
- Hal to send text to Phill

>     H6. AssertionID and IDType need refactoring

- Hal & Phill agree with Eve's proposal
- Eve: AssertionID should be named AssertionIDReference
- consensus agreement

> 6) Spec Refresh

- Joe: need another round of doc revisions by Friday

> 7) Issues from Friday's Focus Call
>    < http://lists.oasis-open.org/archives/security-
       services/200202/msg00005.html >
>    (1) Multiple Subject Issue

- Prateek will send proposed text to list

>    (2) Multiple Signature Issue:

- general consensus was for 0 or 1, proposal would be to change
  occurrence to have minOccurrs=0, and to remove maxOccurs
- Phill directed to add to list of updates

>    (3) RespondWith

- consensus is that absence of RespondWith implies any

>    (4) Time Issue:

- Hal: does item (c) imply timezone 0 or can other timezones be
- Irving: UTC is a specific timezone
- Scott: if we are restricting dateTime, we need to derive a type and
  apply a facet
- ... discussion of whether this is a restriction ...
- Hal: intention is clear, and mechanism needs investigation
- [Action] Scott to do investigation
- BobG: item (d) doesn't sound like conformance issue
- Irving: it would be a very tricky thing to test conformance for
- Irving: MUST part can be tested
- Hal: happy with proposal, just replacing "sub-second" with
  millisecond, since "sub-second" is unclear
- Phill directed to add to list of updates

> 8) Other business

- Hal: we need to state why we chose a versioning mechanism that is
  different than that in XML Schema
- Eve: will write up text

> 5) Adjourn

- Joe: Expect to vote on going to last call and issuing those docs next
- Adjourned


Attendance of Voting Members:

  Allen Rogers Authentica
  Irving Reid Baltimore
  Simon Godik Crosslogix
  Gil Pilz E2open
  Hal Lockhart Entegrity
  Carlisle Adams Entrust
  Robert Griffin Entrust
  Don Flinn Hitachi
  Joe Pato HP
  Jason Rouault HP
  Chris McLaren Netegrity
  Prateek Mishra Netegrity
  Charles Knouse Oblix
  Steve Anderson OpenNetwork
  Jahan Moreh Sigaba
  Jeff Hodges Sun
  Eve Maler Sun
  Aravindan Ranganathan Sun
  Emily Xu Sun
  Bob Morgan UWashington
  Phillip Hallam-Baker Verisign
  Thomas Hardjono Verisign

Attendance of Observers or Prospective Members:

  Rob Philpott RSA Security
  Scott Cantor OSU
  Marc Chanliau Netegrity

Membership Status Changes:

  Rob Philpott RSA Security - granted voting status after con call


tel;work:727-561-9500 x241
org:OpenNetwork Technologies
title:Product Architect
adr;quoted-printable:;;13577 Feather Sound Drive=0D=0ASuite 390;Clearwater;Florida;33762;USA
fn:Steve Anderson

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

Powered by eList eXpress LLC