[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] Minutes for March 26 sstc telecon
I took notes starting right after attendance was recorded. There was a quorum.
Joe: agenda for this meeting have been sent out by
e-mail.
Are there any other outstanding
issues?
When can be ready for a frozen
committee specification?
Bob Morgan:
Are
we still committed to freezing the specification by April 1?
Joe: Yes,
there are very many good reasons to do
so:
(a) fewer
telecons!
(b) other topics are queued
for discussion (e.g., SOAP Profile,
others)
Developer mailing list
information has been published.
PhiL: has published core-28, waiting for
additional comments to come in
before
issuing
core-29.
[RLBob]
InResponseTo optional
proposed text change to core-28 to list - included in spec (Phill?)
http://lists.oasis-open.org/archives/security-services/200203/msg00127.html
[Minutes] Change accepted. Editor to add to
Core-29.
[Hal] New Issue:
Should Queries contain a full Subject?
http://lists.oasis-open.org/archives/security-services/200203/msg00129.html
Choose 1 of 3
options
Regardless of which of
these is chosen, make the following change:
After the end of the sentence
on line 1279, insert a new paragraph:
Note: The AuthenticationQuery MAY
NOT be used as a request for a new authentication using credentials provided in
the request. The AuthenticationQuery is a request for statements about
authentication acts which have occured in a previous interaction between the
indicated principal and the Authentication Authority.
[Minutes]
Scott: There are two distinct issues here:
(1) the specific attack discussed above (2) broader threat to the query-response
protocol.
Joe: We need to figure out which
one of the three choices offered by Hal we plan to follow.
Prateek: I am
concerned about changing the subject element at this stage of the game. In any
case, we still
have possibility of a generic attack on the SAML protocol, for
example, guessing a valid name identifier.
Irving, Eve, Prateek:
discussion of article which lead to Hal's message
Resolution: We will include text to characterize the
general threat described under part 3 of Hal's message. An additional error
sub-status code "Request Denied" and the conditions under which it is to be used
described. No change to schema for subject in
query.
Prateek will write this text and Rob P. will review.
This text will be added to the core document. Motion
passes.
[Hal] [security-services] New (minor) Issue:
AuthNMethod, not ConfirmationMethod in
AuthNQu ery
http://lists.oasis-open.org/archives/security-services/200203/msg00142.html - prateek's proposed changes
[Minutes] Friendly
amendment from Rob --- instruction to the editor -- text beginning at "first,...
and
further, etc..." should be split up into bullets so the processing steps
are obvious.
Motion passes.
[Hal] Text for "All Assertions"
http://lists.oasis-open.org/archives/security-services/200203/msg00138.html - agreed? applied?
lines 1317 & 1318 change the sentence to read:
If no attributes are specified, it indicates
that all attributes allowed by policy are requested.
[Minutes]
Motion passes.
[Scott] Core changes for ISSUE DS-14-19
http://lists.oasis-open.org/archives/security-services/200203/msg00143.html -
[Minutes] Proposed and accepted.
[Emily] Minor error in core 28
http://lists.oasis-open.org/archives/security-services/200203/msg00145.html
[Minutes] Proposed and accepted.
[Scott] Core changes for ISSUE DS-4-13
http://lists.oasis-open.org/archives/security-services/200203/msg00146.html -
[Minutes]
Discussion: Phil
dislikes this change - what is the point of eliminating empty
string/URI?
What about the case where a single character string is sent? Or a
single character URI?
Eve, Scott: At least
eliminates the case where AP and RP "informally" interpret the
empty string
in divergent ways. Helps somewhat by removing this case from
consideration.
Phil: questions cost and messiness of making this change in schema and core document.
Phil: makes a motion to rollback this change.
Eve: maybe we can make this change only in prose? Essentially, declare zero-length strings as not recommended (but not URIs).
Scott: in XML-DSIG no discussion of empty string case. Make it a MUST stronger than recommended.
Joe: action to Scott.
Scott will write text to rule out use of empty strings, rule out empty URIs other than for resources.
[Scott] Approved changes/cleanup for Status/StatusCode/etc.
http://lists.oasis-open.org/archives/security-services/200203/msg00148.html
Scott: explains nature
of proposed changes. Replacement of Receiver by Responder,
Sender by
Requester. Removal of QNAME from enumerated type as it "hardwires" samlp
into
the attribute. Instead this requirement is promulgated in text which avoids the
need for
the literal "samlp".
Phil: When will this be a problem? Only in extensions?
Rob: what has happened to sub-status code?
Scott: becomes an
instance of status code itself. Status code is recursive and can optionally
contain a
further status code within itself.
Joe: move to accept change. Change is accepted and forwarded to Editor.
[Hal] Base64 in core and bindings
http://lists.oasis-open.org/archives/security-services/200203/msg00152.html
Prateek: Is this
an instruction only for binding?
Scott, Rob: what about subject
confirmation data element? This is currently a string and cannot
carry an
arbitrary blob.
Rob: Also occurs in Section 7.1
Joe: any other changes for
core other than making sure the spelling is correct?
Joe: change is accepted. Editors to fix.
[Rob P] Comments on core-28
http://lists.oasis-open.org/archives/security-services/200203/msg00161.html - editorial, applied?
amendments:
4) change
line 352 to start: "currently being defined"
6) replace application by
terms a SAML requestor, SAML responder, where
appropriate
http://lists.oasis-open.org/archives/security-services/200203/msg00163.html - editorial
[accepted]
[Rob P] Issue/editorial comment: Description of<Condition> processing in core-28
http://lists.oasis-open.org/archives/security-services/200203/msg00162.html - agreed? applied?
[accepted]
ADDITIONAL ISSUES
RAISED IN
CALL:
-------------------------------------------------
(1)
Scott:
msg00146 - should the empty string restriction be generalized to whitespace
in the text? Rob moves.
Prateek seconds.
(2)
Prateek: Motion is to
change the type of SubjectConfirmationData to base64binary?
Scott:
Remove ds:KeyInfo and change SubjectConformationData to be
anytype?
Phil: objects to removal of ds:KeyInfo
Scott: why not choose
between the two?
Phil: objects to exclusive choose
Joe: Proposal to change
of SubjectConfirmationData to AnyType.
Motion passes.
(3) RL
Bob's URN message to be applied to core and bindings.
http://lists.oasis-open.org/archives/security-services/200201/msg00225.html
Scott, Joe: explain that these URNs are available.
Joe: Phil +
Prateek to apply changes.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC