OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

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


Subject: Signature Gateway Profile Meeting Minutes


Meeting Minutes
Participants: Trevor Perrin, Nick Pope, Pieter Kasselman, Glenn Benson
Topic: Out-of-band policy
Date: 13-Dec-04

Issue:
We intend the Signature Gateway Profile as a concrete profile.  The first
draft of the Sig Gateway Profile notes that the core provides support for
signature requests, and addition support for verification requests.
However, the core provides little support for combining features of both
request types.

Proposed resolution:
Trevor Perrin proposed that the profile require that the client and server
agree upon a service policy through an out-of-band agreement.  If the
server supports more than one policy, then the client may specify a choice
by explicitly defining the ServicePolicy element.  Furthermore, the client
may request a particular ServicePolicy to force an error if the server were
not able to comply.  The timestamp profile faced a similar issue; and it
employed a similar solution.  That is, the timestamp profile does not
specify the agreement details between the client and server to determine
the specifics of the timestamp format.

Interoperability Definition:
The scope of interoperability does not cover the out-of-band-agreement.  In
other words, if the client and server were to misunderstand the semantics
of the server's policy, then the parties may potentially proceed without
error.   Of course, this scenario would be bad; however, it would be
standard-compliant.  In order to achieve interoperability, all implementers
must interpret the MUST requirements in the same way.  MAYs and SHOULDs
would be considered out-of-scope of an interoperability test.

Proposal to move details out-of-scope:
We could potentially define new elements beyond the core in the Sig Gateway
Profile.  These elements would define the details of a policy.  That is,
they would allow the client to request different policies on a call-by-call
basis.  This fine-grained level of control may be an overkill.  So, this
proposal would eliminate them from the profile.

Possible extension:
Under this proposal, the client and server MUST use an out-of-band method
to agree upon the gateway policy.  If we wish to provide an in-line
agreement method, then we may specify a concrete sub-profile.  We expect
such a sub-profile to be nearly empty.  That is, the sub-profile would only
define a specific ServicePolicy.  DSS recommends the approach of a
sub-profile (rather than an appendix to the Sig Gateway Profile), in order
to avoid the possibility frequent changes to the profile document.



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