Re: [dss] Core and Profiles

["jmessing" <jmessing@law-on-line.com>]

>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.
>
>
I take it that unlike Trevor's approach, the work on "n" would proceed simultaneously with the core work and not sequentially.

I take it this is an approach and not an attempt by enumerating examples of use cases to suggest which ones would be within the protocol without the need for extensions, such as corporate seal, European Notarisation Service, and RFC 3161 equivalent time-stamp.

One concern I have is that we do not yet have a European Notarisation Service use case defined, and in fact that might be somewhat tricky to accomplish since although ETSI may be common to Europe, there are two distinct legal systems: the Civil Law based generally upon Napoleonic Codes, and the Common Law, based upon English Common law. The differences might have to accommodate two very different Notarisation cases, whereas in the United States, because of variations in State laws, one use case with a set of extensions for various jurisdictions might work well.

I raise this example in order to better understand the level of discussion you are proposing and also to alert you as to some of the related programming issues I see occasioned by differences in legal regimes.