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