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] Issue DS 9-10: Schema and text for IssueInstant inRequest/Response


I'm not 100% sure where the consensus landed during the last conference
call on adding IssueInstant to Response as well as Request, but I'm
going to propose adding it to both because it's a more symmetric
addition, doesn't cost anything to do it, and just as with Request, it
could be needed for uses that aren't fully foreseen at this point. If
necessary, think of them as independent proposals.

In protocol-25.xsd, insert after line 16 and line 87:

<attribute name="IssueInstant" type="dateTime" use="required" />

In core-25, add to section 3.2.1, line 877 and to section 3.4.1, line
1068:

IssueInstant [Required]
The time instant of issue of the request/response. It has the type
dateTime, which is built into the W3C XML Schema Datatypes specification
[Schema2].

I don't think anything else is needed in the core document. Issues
relating to time accuracy and so forth should be universal to all
dateTime elements and attributes (maybe this is something that's worth
discussing in the document somewhere?). Specific processing of the
attribute would depend on the binding or profile, just as I think the
Assertion IssueInstant is pretty much not mentioned in core, but is
mentioned in bindings.

I wasn't able to fully understand the context of section 5.4.6.1, but I
think it may not be needed if these are added, since this adds
timestamping to the possible countermeasures available if signing is
used.

I'm not 100% certain what should be added to bindings-09. One possible
approach might be to add text to the Security Considerations section in
the SOAP over HTTP description (lines 263-269) along these lines:

"Since a synchronous SSL connection is used to insure message integrity,
examination of the IssueInstant attributes in Request and Response does
not protect against any known attacks and is not required."

The point to communicate is that for this binding, they can be
completely ignored (thus not costing anybody anything). Maybe nothing
need be said at all, if it's less confusing.

-- Scott



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


Powered by eList eXpress LLC