RE: [dss] Further - Request for inclussion to the requirementsdocument

[Trevor Perrin <trevp@trevp.net>]

At 09:43 AM 5/13/2003 +0100, Nick Pope wrote:

>Trevor
>
>The term "Profile" is generally used for selecting options within an
>existing specification.

I'm using "signature profile" to mean a profile of an existing signature 
specification like XML-DSIG/XAdES or CMS, which specifies how things like 
requestor identity or an XML timestamp are added to them.


>What we are suggesting in b) is the extending of the elements defined in the
>Core with some additional elements.
>
>Then in c) We suggest that for a particular use case we select those
>elements relevant to a particular usage.

Can we squish these together?  I.e., if we define an XAdES Signature 
Profile that specifies how to identify the requestor and attach XML 
timestamps within XAdES, and the same for CMS, then what else is left for 
(c) to do?  I.e., what else do we have to profile for particular use 
cases?  Could you give examples?



>Independent of the number of documents required do you agree with the clear
>difference between adding elemenets to the core and a profile.
>
>Also, the list you produce for the core is not exactly the same as we
>suggest.  What is "XML Simple"?

sorry, read that whole bullet as refering to the time stamp and mark 
elements.  Simple as opposed to linking.


>Also do you agree that the "signature
>Policy" (which already included in the requirements document) should be
>included in the CORE.

In my imaginary "Protocol and Core Elements" doc I was only putting in new 
elements that we need to define.  XAdES already has a signature policy 
element, so I wasn't putting it in there.

Trevor


> > -----Original Message-----
> > From: Trevor Perrin [mailto:trevp@trevp.net]
> > Sent: 13 May 2003 00:06
> > To: Juan Carlos Cruellas; dss@lists.oasis-open.org
> > Subject: Re: [dss] Further - Request for inclussion to the
> > requirementsdocument
> >
> >
> > At 07:10 PM 5/12/2003 +0200, Juan Carlos Cruellas wrote:
> >
> > >Trevor,
> > >
> > >Following the discussion on the roadmap and
> > >core/profiles, we would like to submit to your consideration the
> > >following:
> > >
> > >a) In the definition of the DSS protocols, we could work on
> > >a two-dimensional matrix, whose dimensions would be:
> > >
> > >  1. Sets of elements (attributes) to be included in the signatures and
> > >in consequence to be managed by the DSS request/response protocols.
> > >(XAdES, CMS and potential future documents would bring them into
> > >the scene).
> > >
> > >    2) Profiles associated WITH use cases.  A profile selects specific
> > >elements relevant to the associated use case.
> > >
> > >b) The DSS protocol elements would then include:
> > >
> > >   - Core DSS elements
> > >       Basic Rq / Response Protocol
> > >       W3C XML Signature
> > >       Time-stamp and time mark elements
> > >       XML requestor identity elements
> > >         XML Signature Policy element
> > >       (Note the above is inluded in parts of the requirements document)
> > >
> > >   - Additional DSS element sets
> > >       XAdES additional element set
> > >       CMS additional element set
> > >
> > >
> > >c) The relevant DSS elements for a particular use case are
> > selected through
> > >a use case profile.  Example use cases are as identified in the
> > DSS use case
> > >document.  A few profiles may be defined by DSS group.  Other would be
> > >defined externally by other communities (this would include a European
> > >Notary Profile - which was an unfortunate example as it has many issues
> > >outside DSS).
> >
> >
> > Juan Carlos and Nick,
> >
> > I think we agree on a lot, modulo some terminology.  I suggested
> > we produce
> > 2 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?)
> > (http://lists.oasis-open.org/archives/dss/200305/msg00024.html)
> >
> > This seems mostly the same as your (b), but it makes the division into
> > documents explicit, and it uses the term "signature profile" for
> > something
> > like XAdES, instead of calling it an "element set".  Would these 2
> > documents address everything you mention in (b)?
> >
> > In your (c), you envision "use case profiles".  It sounds like this would
> > further profile what I call a "signature profile" or what you call an
> > "element set" for a particular use case.  I was hoping the "signature
> > profiles" would make it clear how to address all the various use cases
> > (i.e., they'd clarify how to identify the requestor, or attach a
> > time-stamp, within a particular signature format), so I'm not sure what
> > else would be in a "use case profile".  Could you give examples?
> >
> > Trevor
> >
> >
> >