Carlos,
Agree in general on your suggested
baselines. I wondered about even separating out the signing & verification.
As they are relatively independent I can see implementations sometime support
one but not they other. I see no problem with an implementation supporting
several profiles.
I suggest that we leave the all the
existing optional inputs /outputs where they are in the Core so that other
profiles
Perhaps the transport can be conformance
options within the profile. Should one be required for interopability?
I would not expect the baseline profiles
would "extend" the core. Rather I would expect it select to select
options defined within the core that would be required to conform to a particular
baseline profile.
As for asynchronous I suggest that the
existing approach of defining an "abstract profile" that can be selected
by implementations to add to the baseline would be OK.
Nick
-----Original Message-----
From: Carlos Gonzalez-Cadenas
[mailto:]
Sent: 12 March 2007 12:14
To: Pope, Nick
Cc: Juan Carlos Cruellas;
Subject: Re: ResponseBaseType and
profiles
Nick,
Yes, I consider that it's practical to implement the core with all forms of
signature supported. You can think about "validation service
providers" that are used by different clients (each one having different
kinds of signatures, i.e. CMS / XML).
In the other hand, it's not clear for implementers which is the minimal subset
of the protocol needed to claim compliance with DSS core (well, it seems that
it's the whole core). I agree with you that creating "baseline"
profiles (one for every "major use case" ( i.e. XML
signatures(creation/validation), CMS signatures(creation/validation), XML
timestamps(creation/validation), CMS timestamps(creation/validation)) would
help a lot, in this way the implementers can choose which "packages"
they do implement.
I would move to these "baseline profiles" the optional inputs/outputs
that are specific for this kind of signature, so they don't mess in the other
baseline profiles, and I would leave the common optional inputs / outputs in
the core.
I would also leave the security/transport protocols in the core, as they
are orthogonal to the "big use cases", so if there's no constraint in
the "baseline profile", any of these protocols can be used.
So, for me (and I understand that this is also your proposal), the core in
itself is abstract, and the "implementable" parts are the
"baseline profiles" that extend the core.
As another side comment (very important for me), in DSS the only way to add
optional functionality to the protocol is to create a profile. In many cases,
these "profiles" only add some "feature" (in the form
of a number of optional inputs / outputs) to the base. I would like to see
support in DSS (as a first-class citizen) for a lightweight form of "profiles",
called "features" or "capabilities" (look for example at
SPML). These features can be implemented on top of any of the profiles when
needed.
I don't think we need a full profile for defining i.e. the
"asynchronous" capability. This should be a
"feature"/"capability" defined in the core (that include
several optional inputs / outputs). I see that this approach has several
advantages:
more clear: the implementers see "packages
of functionality" that they implement or not depending on their
needs (¿do I need async processing or not? ¿do I need policy support or
not? ...). Even an implementation that contains all the features
implemented can be later operated activating some features at
runtime.
more manageable: for the TC, to have tens of spec
documents is hard to manage. I see that profiles should only be used for
"big things" (i.e. the baseline profiles for every big "use
case" or, as another example, the XAdES profile), not to add two
optional inputs/outputs. For me, every "feature" should deserve
a mini-chapter (one or a few pages) in the core or in some profile (if the
feature is local to a profile), like what the folks at SPML are doing.
Regards,
Carlos
PS: BTW, is this going to DSS 1.x or DSS 2?. In this case I would like to
discuss some modifications that are relevant in the light of this proposed
modification.
On 3/12/07, Pope,
Nick <>
wrote:
Carlos,
Is it practical to implement the Core with all forms of
signature and transport data to the server? I would suggest rather we
define two "baseline" profiles on for CMS the other for XML
using perhaps SOAP with data carried as a MIME object.
Nick
-----Original Message-----
From: Carlos Gonzalez-Cadenas
[mailto:]
Sent: 11 March 2007 16:04
To: Pope, Nick; Juan Carlos
Cruellas
Subject: dss:ResponseBaseType and
profiles
Nick, Juan Carlos,
The response base type (dss:ResponseBaseType) requires to include the profile.
Which value is expected for responses produced by servers that implement only
core (no profiles) ?.
In my opinion, this attribute should be optional, as in its analogous type dss:RequestBaseType.
Regards,
Carlos
