Re: [dss] Profile Integration proposal

[Trevor Perrin <trevp@trevp.net>]

At 02:02 PM 4/5/2004 +0200, Andreas Kuehne wrote:
>Hi Paul,
>
>Thank you for putting the profile pieces together in one document !

I second that, this is a very good explanation of the profile model.  The 
few things I would change:
  - Under the "PM" note, it almost sounds like the code-signing profile is 
being called "implementable", which isn't correct.
  - I don't think all abstract profiles need URIs, but I agree URIs could 
be useful for abstract profiles (such as for code-signing, in establishing 
a base URI that the sub-profiles extend).
  - A profile might derive from *multiple* super-profiles, in which case 
you can't expect the URI to extend the super-profile's URI.  This could be 
noted.
  - The "Note" at the end isn't clear to me.


>As you outlined the profiles do work just in an inheritance mode. The 
>abstract profile gets implemented by a concrete profile which in turn can 
>be specialized by a subprofile.
>
>The only way to aggregate profiles of different target dimensions ( 
>vertical vs. horizontal ) is to define a new combination profile. I'm 
>afraid  we will see a combinatory explosion of profiles with just being a 
>combination of two or three other profiles. So I would suggest to 
>aggregate the different profiles at runtime, giving not only one, but a 
>set of profiles with the SignRequest structure. I know this is a big 
>change to the core protocol, but I would help us to keep different things 
>separated. For example the GermanSignatureProfile has intentionally 
>nothing to do with the XAdES or a CMS profile. So why tie two profiles 
>together in a combinatory subprofile ?
>
>Problems may get worse, if more horizontal profile evolve ...

It would be really hard to dynamically compose profiles.  For example, the 
German Signature Profile disallows <DocumentHash>, but some other profiles 
might allow it or even mandate it (like the time-stamping profile).

I agree there could be a problem with "combinatory explosion", particularly 
trying to combine horizontal profiles (like policy-wise, and german 
sig-law), with vertical ones.  I don't see any generic solution to this we 
can put in the core.

However, if a particular concrete profile wants to subclass several 
incompatible horizontal profiles, then it could define some new optional 
input(s) as selectors to switch between policy-wise/non-policywise, German 
Sig-Law/Belgian sig-law/French Sig-Law, etc..  I think it needs to be up to 
the concrete profile to define these selectors, not the core, since the 
details of what they mean, how many of them are needed, etc., will vary.


Trevor