SSTC call notes - 2004-10-26

[John Kemp <john.kemp@nokia.com>]

Minutes for OASIS SSTC conference call Tuesday 2004-10-26
Minute taker:  John Kemp

Summary:

  Votes:
  -- factor out type for NameID, Issuer, allowing consistent use of 
different format defaults for each

  Extended discussion:
  -- (none)

  New action items:
  -- Eve to explain extension of Attribute (see discussion in notes)
  -- Scott to respond to question about unqualified vs qualified in 
schema defaults (that we're not going to anything)
  -- Scott to respond to query about encryption ciphertext being unique, 
affirming decision to require this
  -- Eve to analyze/correct usage of SAML entity terminology
  -- Scott to analyze/correct usage of terms regarding principal, 
subject, user et al

  Current action items:
  -- 197: closed
  -- 160: Prateek almost done
  -- 123: Jeff has prompted IESG, should be done by early next week
  -- 199: ongoing, contains multiple actions, Eve will add official APs 
for these


Raw notes:

roll-call determines that we have a quorate call (participant list to 
follow under separate cover)

eve: agenda notes review period ends on Halloween, with focus call next 
week to tie up loose ends. Eve reminds group about various important 
issues regarding attestations, votes, asks for questions.
hal asks about agreed-upon granularity for attestations
discussion about attestations
scott: discussions were had about attestations being related to pieces 
of core spec. not outlying functionality
gregw: When's IOP?
rob: If we don't get attestations, we have to delay the vote
(discussion about requirements for attestations)
eve: vote to accept changes to cd-02a drafts
rob: had comments on core, not included in the 02a drafts
peter: did you incorp Dave McAlpin's input?
scott: if agreed with Dave, I incorporated changes
scott: took out some MAYs particularly in proxy restriction
eve: changes improve the clarity
scott: outstanding issue around whether a particular condition is truly 
binding (ie. MUST)
eve: emphasize review of changes, discuss outstanding items
scott: made schema changes that corrected mistakes, also added consent 
attribute to Response message
scott: didn't do much to profiles
scott: fixed examples in bindings - especially the URL/gzip-encoding
scott: noted that metadata spec is not authoritative, made other small 
clarifications
scott: gregw noted that URI namespaces were an issue when versionining - 
when profiling metadata spec. this is the URI you should put in this 
attribute to indicate the version. This is clarified in 02a

eve: comment about "friendly name" needing a 'lang' attribute.
(discussion about internationalizing between Eve and Scott)
scott: if we think he's right about internationalizing, we should "pull it"
RLBob, Rick Randall join
rlbob: FriendlyName is of questionable value, thus further describing it 
seems unnecessary
rob: maybe consider this for a future release?
scott: why can't you (some external org) extend, and xsi:type this with 
a 'lang' attribute into their document?
eve: perhaps just explain how to extend Attribute to do this?

AP: Eve to explain this

(discuss general editorial comments from 
http://lists.oasis-open.org/archives/security-services-comment/200410/msg00000.html)
scott: received comments on schema defaults. qualified vs unqualified
eve: consensus seems to be that we do nothing about 'unqualified'

AP: Scott to respond

scott: (explains issue regarding contradictory use of 'format' default 
in Issuer. Factor out the type, to allow this?)
rob: (comments further about clarification around source ID)

VOTE:

scott: moves that we factor out the XML type of NameID, Issuer, allowing 
them to have different default values.
gregw seconds
any discussion? nope
unanimous consent, vote carries

scott: encryption algorithm MUST result in unique ciphertext - comment 
received that this should be SHOULD
(resolve to re-affirm this in email)

AP: Scott to re-affirm in email

scott: we say what constitutes an invalid assertion, but don't say what 
to do if it is invalid - so why make it a MUST to evaluate whether the 
assertion is invalid?
rlbob: profiles can decide this
eve: Can we make this a SHOULD?
hal: can we go the other direction, and say what one should do when the 
assertion is determined invalid? So, should we say that you shouldn't 
depend on the assertion?
rlbob: intent is that condition MUST be evaluated
hal: tests can't determine whether a condition was "taken into account"
johnk: his point is exactly that - that you can't test this for conformance
nick: even though you can't test, the normative rule has a role in 
conformance
scott: suggest that we change Core to say that you shouldn't depend on 
the contents of the assertion if invalid
hal: historical argument was about Audience restrictions
rlbob: this is a loose evaluation of the condition
eve: what to do?
rlbob: we need text about general processing of assertions and what you 
should do if invalid
eve: can we add something about evaluation?
scott: can we get the rules straight, do implementation guidelines for 
now, and then add to the spec. in the correct places later?
scott: evaluation of signature, conditions, evaluation of issuer - all 
of these are in the spec. - tighten up conditions language, and if 
result is invalid or indeterminate the assertion MUST be discarded.
eve: instruction to the editor to make this change
scott: line 561 comment - change the MAY to may
scott; SubjectConf data line 682, 687 comments. More consistent 
definitions requested - this is reasonable. Will work to do this
scott: line 790 - 808 comments explain that rules for evaluation of 
conditions are inconsistent and contradictory.
scott: will add text from 818 to third bullet of  814, 815
scott: line 1000 - the MUST NOT is inconsistent
eve: perhaps should be SHOULD NOT, with text to explain - the reason 
being that privacy is not important to your implementation?
scott: will formulate text, distribute.

eve: change to definition of "identity federation"
prateek: respun based on Scott's comments

back to agenda item 4 (c) and (d)

(c) Question about XML-ENC use of XMLDSIG namespace vs. SAML use

http://lists.oasis-open.org/archives/security-services/200410/msg00041.h
tml


(d) Editorial input on profiles document

http://lists.oasis-open.org/archives/security-services/200410/msg00054.h
tml

(d) Scott will respond
(c) Scott: a tool issue. Shouldn't change the URI reference. (No action)

eve: let's address Rob's concerns

Numbers below reference email: 
http://lists.oasis-open.org/archives/security-services/200410/msg00058.html

1.

scott: rob's comment - SLO - should partial logout roll-back successful 
logouts? No, partial success is fine
gregw: (agrees)

2.

scott: discussed before, will remind Rob of previous decision

3. ? (minute-taker missed this apparently)

4.
scott: put some forward references to the extension section

5. terms for SAML entities are confusing - rob suggests that we make 
sure our terminology is correct in each place it appears, and note that 
terms overlap -

eve: will attempt to analyze usage of terms, make sure we're using terms 
correctly, and find the right place to put commentary around this.

AP: Eve to analyze/correct usage of SAML entity terminology

6. Sloppy language around principal, user, subject - Scott will take this on

AP: Scott to analyze/correct usage of said terms

7. Editorial issue around sections in the introduction - create a 
section 1.3 that includes schema datatype interpretations etc. etc.

Review current APs

197: closed
160: Prateek almost done
123: Jeff has prompted IESG, should be done by early next week
199:  ongoing, contains multiple actions, Eve will add official APs for 
these

eve: AOB?
gregw: been testing metadata between SAML 1.1, SAML 2 - is there 
interest in documenting a common profile of metadata for SAML 1.0, SAML 
1.1 implementations using the SAML 2.0 metadata?
eve: create a whitepaper?
gregw: volunteers to write up a profile, discuss on a focus call.

ADJOURN