OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: ResponseBaseType and profiles



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.




-----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



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.



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:



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.





-----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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]