Re: [dss] Core and Profiles

[Trevor Perrin <trevp@trevp.net>]

At 04:14 PM 5/7/2003 +0200, cruellas@ac.upc.es 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