Carlos,
I think that we are in general agreement.
You may be right that the asynch profile is different from the others.
Juan Carlos - perhaps you could add "baseline
profiles" to the list of work items.
Nick
-----Original Message-----
From: Carlos Gonzalez-Cadenas
[mailto:carlos@gonzalez.name]
Sent: 12 March 2007 14:49
To: Pope, Nick
Cc: Juan Carlos Cruellas;
dss@lists.oasis-open.org
Subject: Re: ResponseBaseType and
profiles
Nick,
Agree with the different profiles for signing / verification.
Regarding the "abstract profiles", my understanding of an
"abstract profile" is that it's one that cannot be directly
implemented (but can be further profiled in a concrete(implementable) profile).
The AdES abstract profile is a good example for that, further profiled by
the concrete profiles XAdES and CAdES.
In contrast, the asynchronous profile is another kind of thing, because it's
not intended to be a "standalone profile", but an orthogonal
feature (orthogonal to a "standalone profile") that customizes
the behavior of the "standalone profile" (in this case allowing the
response to be deferred in an asynchronous way). Note that even the invocation
method is different (the asynchronous profile is never expected to be used via
the Profile attribute of the request, but instead with the
dss:AdditionalProfiles). I think that explicitly differentiating these two
things can bring a lot of clarity to this issue.
Regarding the optional inputs / outputs location, I agree that maybe it's
better to have them in the core (for a cleaner reusability model for profiles).
In this way, the baseline profiles don't extend, but select what kind of
contents and what kind of optional inputs / outputs can be used in this
profile.
Best regards,
Carlos
On 3/12/07, Pope, Nick <Nick.Pope@thales-esecurity.com>
wrote:
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:carlos@gonzalez.name]
Sent: 12 March 2007 12:14
To: Pope, Nick
Cc: Juan Carlos
Cruellas; dss@lists.oasis-open.org
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 <Nick.Pope@thales-esecurity.com>
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:carlos@gonzalez.name]
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
|