At 04:14 PM 5/7/2003 +0200, wrote:
>Content-Transfer-Encoding: 8bit
>
>Dear all,
>
>Following discussions at the DSS TC meeting there seems to be a need for
>clarification of what is meant by Core and Profile and how the DSS
>specifications might be organised. This mail puts forward some initial
>thoughts on this topic.
>
>The first question is what is the Core? I presume by Core peolple mean what
>we define first of all. So looking at options of what we define first:
>
>a) the "central core" which is the basic protocol which defines "buckets"
>into which the information required by the use cases is carried, but not
>what the information is, along with basic CMS /XML signature syntax. This
>central core would only define those elements or protocol and signature
>syntax that are applicable to all use cases. Such a "central core" would
>not on its
>own be of much use as most cases would require more information than the
>basic XML Digitial signature which will be present in every use case (except
>those using CMS). All the DSS use cases would need to define extensions to
>the "central core".
>
>b) The "central core" plus that information which is required by "n" use
>cases. The problem lies with how do we decide how big is "n".
>
> - If "n" is the large majority then the chances are that nearly every use
>case will have to define extensions to the DSS specification
>
> - If "n" is just one then then the DSS specification will be too big with a
>multitude of options that it will never be completed or understood.
>
>
>We would suggest the DSS includes information which is likely to be used in
>more than one of the most likely use cases. We suggest that the
>specification err towards being inclusive of many use cases, rather than
>taking a "minimalist" approach.
>
>
>Next on to profiling.
>
>Our suggestion following on from the above is that having defined the
>DSS protocol for a specific use case, e.g. corporate seal, European
>Notarisation Service, RFC 3161 equivalent time-stamp, the specific
>information/protocol element needed for that use case will need to be
>selected. For some use cases extensions to DSS will need to be defined
>specifically for that use case. A few widely used profiles would be
>defined / approved by the DSS.
Juan and Nick,
it seems like your thoughts are consistent with my "roadmap" post. Would
you agree?
http://lists.oasis-open.org/archives/dss/200305/msg00024.html -
"Baseline Documents
-------------------
Protocol and Core Elements:
- request/response protocol
- XML simple (but extensible) time-stamp and time-mark elements
- XML requestor identity element
Protocol Bindings and Signature Profiles:
- XAdES XML-DSIG profile
- CMS profile
- Other profiles?
- Bindings (WS-Security? others?)
Follow-on Work
-----------------------
XML linking time-stamp element
[Additional Bindings and Profiles]"
Trevor
