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 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?)


[Minutes] Change accepted. Editor to add to Core-29.

[Hal] New Issue: Should Queries contain a full Subject?


        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.

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.

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


[Minutes] Proposed and accepted.

[Scott] Core changes for ISSUE DS-4-13

http://lists.oasis-open.org/archives/security-services/200203/msg00146.html -


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.


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


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?


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


[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?


Scott: msg00146 - should the empty string restriction be generalized to whitespace in the text? Rob moves.
Prateek seconds.


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.
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