[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 http://lists.oasis-open.org/archives/security-services/200202/msg00002.html <http://lists.oasis-open.org/archives/security-services/200202/msg00002.html > Irving: What about being able to ask for "All AuthN statements about Irving 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: http://lists.oasis-open.org/archives/security-services/200201/msg00262.html <http://lists.oasis-open.org/archives/security-services/200201/msg00262.html > General consensus: there is no requirement to support multiple signatures (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: http://lists.oasis-open.org/archives/security-services/200201/msg00237.html <http://lists.oasis-open.org/archives/security-services/200201/msg00237.html > 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 multiple requests. <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 Request. 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 NotOnOrAfter: 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 3.2.7.2. Unfortunately, there does not appear to be a simple way to express this within schema itself. (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