[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] Minutes for Telecon, Tuesday 28 May 2002
Minutes for SSTC Telecon, Tuesday 28 May 2002
Dial in info: +1 334 262 0740 #856956
Minutes taken by Steve Anderson
>
> The focus for this week's meeting is to tie up any loose ends prior to
> submitting the SAML 1.0 specs for consideration as an OASIS spec.
>
> Agenda:
>
> 1. Roll call
>
- Attendance attached to bottom of these minutes
- Quorum achieved
>
> 2. Consensus test that we do want to submit into the 1 June OASIS
> review cycle - failure to reach consensus will cause us to adjourn
> and continue as a focus group meeting
>
- Who does not believe we should be submitting?
- no one
- Consensus is that we do want to submit
>
> 3. Any residual technical issues (esp. inclusion of fixes to errata
> in specs)
>
> There are 5 new PEs (potential erratas) in draft-sstc-cs-errata-02
> to discuss.
>
> see..
>
> Errata document V02
> < http://lists.oasis-open.org/archives/security-services/
> 200205/msg00050.html >
>
- Eve summarizes where we are
- PE14-PE22 are open
- a couple will need thought, but rest should be trivial
- PE4 had action item, but has been resolved
- PE14-22 need to be decided on today
- Walking through PE's
- PE14: Fix references to time values section
- Eve moves to fix these
- [VOTE] no opposition, approved
- PE15: Unify signature inheritance subsections
- this one's more meaty
- Irving: brought up concern in F2F#5
- recalls that the intent was for the restriction to be there
- Prateek: so you're just re-affirming what is in there?
- Irving: found first paragraph confusing, mentioning inheriting
signatures from anything, but later we say signatures can only
be inherited from surrounding SAML
- Prateek: notice term "rationale" in 5.3.1, implying
non-normative
- Irving: options are to revisit intent (which would have to be
defined by profile) or fold a little of 5.3.1 into 5.3.2
- re-opening sounds like a bad thing
- Prateek: profiles still can define signature rules
- Eve: inclined to dump wording in PE15, and follow Irving's
direction
- Irving will craft some wording while we proceed
- RLBob: comments on term "signed SAML" being unclear
- Irving: there are some parts of SAML where signatures are
allowed
- RLBob: write that down
- deferring item for the moment
- PE16: Remove schema listings in back of core
- Phill: uncomfortable removing this, as people may not refer
to the schema file
- we've not had problem keep them in sync
- Eve: actually we have, see PE13
- Eve moves to remove them
- [VOTE] no opposition, passes
- PE17: Remove mention of <AdviceElement>
- Eve moves that we remove the mention
- [VOTE] no opposition, passes
- PE18: Interpretation of authentication information
- requires a little thought
- Prateek: believes these were supposed to be required
- believes misunderstanding stems from attributes needed to be
flagged as required, otherwise they are optional
- Phill: can imaging cases where method may not want to be
revealed
- Eve: could have URI that specifies "none of your business"
- Eve: this would be a schema change if this becomes required
- Prateek: we've implemented as required
- several others did as well
- Rob: would it be appropriate to add that method (in 7.1.11)
for "not specified"?
- Phill: suggests devices may not have ability to generate
good timestamp
- Prateek: no presumption that it is a good clock
- Bhavna: nowhere else stipulates a "good clock", so why make
this one inconsistent?
- Eve: moves to change the prose and schema to make these
required
- RLBob: makes friendly amendment to specify the "unspecified"
authN method
- Eve: accepted
- [VOTE]
- Phill opposes
- passes with one objection
- PE19: Clarify the SubjectLocality element
- Joe: do we have specific change text?
- Eve: no
- Rob: not against leaving as is
- Eve moves to accept option 2, not changing it
- [VOTE] no opposition, passes
- PE20: ResourceNotRecognized not found
- Prateek: moves to add status code
- Joe: we do need text here
- Eve: friendly amendment of proposed text
"The responder does not wish to support resource-specific
attribute queries, or the resource value provided is invalid
or unrecognized."
- [VOTE] no opposition, passes
- PE21: Equality of major and minor versions
- much wordsmithing ...
- motion to accept:
"The specifications may be revised without a change to the
SAML major or minor version number, as long as the
specification changes raise no compatibility issues with SAML
implementations."
- [VOTE] no opposition, passes
- PE22: Delete reference to "AuthorityKindType" in line 707 of
cs-sstc-core-00.pdf
< http://lists.oasis-open.org/archives/security-services/
200205/msg00055.html >
- Eve moves to make this editorial change
- [VOTE] no opposition, passes
- PE15 (revisited)
- Irving sent proposed text to list in
< http://lists.oasis-open.org/archives/security-services/
200205/msg00056.html >
- Prateek: friendly amendment "but is contained in an enclosing
SAML element"
- new text:
"A SAML assertion may be embedded within another SAML element,
such as an enclosing saml:Assertion or a samlp:Request or
samlp:Response, which may be signed. When a SAML assertion
does not contain a ds:Signature element, but is contained in
an enclosing SAML element that contains a ds:Signature, and
the signature applies to the saml:Assertion element and all
its children, then the Assertion can be considered to inherit
the signature from the enclosing element. The resulting
interpretation should be equivalent to the case where the
Assertion itself was signed with the same key and signature
options.
Many SAML use cases involve SAML XML data enclosed within
other protected data structures such as signed SOAP messages,
S/MIME packages, and authenticated SSL connections. SAML
profiles may define additional rules for interpreting SAML
elements as inheriting signatures or other authentication
information from the surrounding context, but no such
inheritance should be inferred unless specifically identified
by the profile."
- Eve moves to accept
- [VOTE] no opposition, passes
- Eve: we have now closed all errata, and new draft of errata doc
should be out this afternoon
- new rev of docs & schema should be ready 30 May, so 31 May will be
last chance to say "Eve, you missed one"
- Errata doc will change again after that to reflect disposition change
to "incorporated"
- Eve: would be nice to have extra pairs of eyes committed to double-
checking
- Krishna & Prateek commit
>
> 4. Verification of company attestations - esp. note Karl Best's
> message citing policy section 3.2(A) indicating that each
> implementation must have taken "adequate steps to comply with any
> such [IPR] rights". We will review briefly what that means for
> SAML and I'd like each implementer to have considered the RSA IPR
> claims and what that means to them.
>
- Joe: only 1 IPR claim presently (from RSA)
- there are no formal steps provided from RSA at this time
- Rob: RSA had committed to getting a process to the committee by 31 May
- he believes it should not hold up anyone's attestation
- Joe: so details will come too late to alter submission, but in month
of June, details could cause parties to withdraw attestations, and
cause us to pull spec submission
- we will lose face significantly in this event, so all parties
must be prepared to work this out
- Joe: implementers need to re-assert attestations
- done verbally on call
- Charles: does this apply only to browser POST profile, or to
everything?
- Rob: there are other scenarios outside of POST profile that are
covered by patent
- Joe: so we are still a "go"
- Joe: looking for 3rd attestation of Req/Resp of AuthZ
- Prateek: Crosslogix claims to support this
- Joe: that would make the 3rd
- Joe: any discomfort making attestation claims less granular?
- motion: "We have determined that there are more than 3 independent
implementations of SAML, and details will be made available later"
- [VOTE] no opposition, passes
>
> 5. Vote to approve spec with errata fixes to be submitted to OASIS as
> a candidate specification.
>
- motion to approve spec with errata fixes to be submitted to OASIS as
a candidate specification
- [VOTE] no opposition, passes
- << and there was much rejoicing ... yeah >>
>
> 6. New Business
>
- Creation of liaison to the Joint Committee on Security
- Intent of committee to coordinate direction on security
- each security-related committee needs to create a liaison sub-
committee
- currently, Joe and Jeff are named for SSTC
- Joe prepared to attend as the putative liaison sub-committee
- Krishna: would like to be part of sub-committee
- Phill: believes lots of this group would like to participate
- Krishna: what is relationship between the JC and the TAB (Tech
Advisory Board)
- Joe: not defined yet
- motion to name Joe & Jeff as the formal liaison sub-committee,
which will be re-addressed in future SSTC meetings
- [VOTE] no opposition, passes
- Schedule of future SSTC concalls
- Joe: doesn't want weekly, anyone suggest less frequent than every
to weeks?
- none
- Will remain bi-weekly
- RLBob: attendance and membership rules continue?
- Joe: yes
- Prateek: has put doc on table of unfinished business and would like
TC to take it up for consideration
- motion to take this up as first priority
- [VOTE] no opposition, passes
- Krishna has a road map to propose
- Krishna raises issue of Kerberos
- Rob: should we consider overlapping work on other specs, e.g.
WS-Security, XrML?
- much discussion ...
- the spirit of the committee is that are strong reasons to look
for collaboration, and over the next weeks (and in particular, on
the next call in two weeks), we will be brainstorming ways to
accomplish this
- TC is asking Phill, as a member of the authoring group, to extend
an invitation to the rest of the authoring group to join us in
that brainstorming session
- Rob: another item is a registry for new authN methods, etc
- Joe: can this be part of the road map effort?
- Rob: sounds fine
- Prateek: would add to that the bindings & profiles, which is
essentially the same spirit
- Joe: assignments
- Prateek will lead the SAML SOAP Profile
- for the road map, need people to outline and bring to committee
the topics 4 weeks from now
- volunteers will be solicited at next call (11 June)
>
> 7. Adjourn
>
- Adjourned
-----------------------------------------------------------------------
Attendance of Voting Members:
Allen Rogers Authentica
Irving Reid Baltimore
Krishna Sankar Cisco
Carlisle Adams Entrust
Don Flinn Hitachi
Joe Pato HP
Marc Chanliau Netegrity
Prateek Mishra Netegrity
Charles Knouse Oblix
Steve Anderson OpenNetwork
Rob Philpott RSA Security
Jahan Moreh Sigaba
Bhavna Bhatnagar Sun
Eve Maler Sun
Emily Xu Sun
Bob Morgan UWashington
Phillip Hallam-Baker Verisign
Attendance of Observers or Prospective Members:
Robert Griffin Entrust
Robert Zuccherato Entrust
Simon Godik Crosslogix
Membership Status Changes:
Robert Griffin Entrust - granted voting status after call
Robert Zuccherato Entrust - granted voting status after call
--
Steve
Attachment:
sanderson.vcf
Description: Card for Steve Anderson
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC