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] Minuets of Discussion at 12 noon, February 1

in attendance:
Chris McLaren, Simon Godik, Irving Reid, Rob Philpott
Consensus on the following topics:
(1) Multiple Subject Issue
     General consensus around the position taken in
    Irving: What about being able to ask for "All AuthN statements about
    that involve some specific ConfirmationMethod (e.g., public Key)?". This
cannot be 
    expressed at this time. 
    Prateek: Very likely to be required in future, but we should defer for
SAML 1.0.
(2) Multiple Signature Issue:
    General consensus: there is no requirement to support multiple
    (0 or 1 good enough). While XML-DSIG supports multiple signatures, it
    only complicates matters for us (e.g., what is the processing model?).
(3) RespondWith:
     Original message:
    Suggested Text:
    The <RespondWith> element specifies the type(s) of response that is
    acceptable to the requestor. Multiple <RespondWith> elements MAY be
    specified to indicate that the requestor is capable of processing
   <RespondWith> elements are used to inform the responder of the type of
   assertion statements that the requestor is capable of processing. The
   Responder MUST use this information to ensure that it generates responses
   consistent with information found in the <RespondWith> element of the

                           NOTE: Inability to find assertions that meet
<RespondWith> criteria
                           should be treated identical to any other query
for which no assertions are 
                           available. In both cases, we would expect a
status of success to be  
                           returned in the Response message, but no
assertions to be found therein.
  (4) Time Issue:
        (a) Stay with NotOnOrAfter (current formulation)

        (b) Standard mapping available from X.509 time intervals into
                     Add 1 second to X.509 time end point. 
                    This provides the corresponding NotOnOrAfter value as
                    X.509 is limited to 1 second resolution.

         (c) dateTime values should always be interpreted in UTC format. In
other words, values are limited to the canonical representation described in Unfortunately,
there does not appear to be a simple way to express this within schema
         (d) Following text is proposed for the Conformance document:
         Issuers SHOULD NOT rely on granularity of time finer than
sub-seconds (milliseconds)
         In determining validity of assertions, relying parties MUST evalute
time upto sub-seconds (milliseconds).

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC