RE: [dss] Profile Integration proposal

[Paul Madsen <p.madsen@entrust.com>]

Trevor/Andreas, thanks for comments

inline

>-----Original Message-----
>From: Trevor Perrin [mailto:trevp@trevp.net]
>Sent: Monday, April 05, 2004 10:45 PM
>To: Andreas Kuehne; Paul Madsen
>Cc: 'dss@lists.oasis-open.org'
>Subject: Re: [dss] Profile Integration proposal
>
>
>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.

That was my interpretation/guess. If its not the case (ie. code-signing is
not implementable withotu further profiling) then the distinction between
code-signing and policy-wise is merely that one targets a specific
application and the other not.

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

To my mind, since abstract profiles can only ever be relevant through their
profiling, they need URIs (for just the reason you state). 

For concrete profiles, its not a given that they will be further profiled
and so wont not need a URI for that reason, but of coure require one for use
in the 

Agreed, the issue however is how to determine, at the time an abstract
profile is being defined, whether or not it will subsequently be 

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

Good point, perhaps a concrete example might be if Frderick's WSS profile
didn't itself account for the policy-wise scenario, then it would be
relevant to capture the combination.

Somebody else could define a new profile with either of the identifiers
'pws:wss' or wss:pws' 

The alternative would be Andreas's suggestion below to allow the requestor
to indicate both 'wss' and 'pws' in its request and place the burden of
interpretation on the DSS server. We would likely need to define an
corresponding fault message for 'no intersection of profiles'.



>  - The "Note" at the end isn't clear to me.
>

Merely that, if the DSS Server could determine the appropriate sub-profile
by examing which elements are or aren't present in the request, then it
would be sufficient to merely label the super-profile with a URI. This
implies alot of work and processign for the server so it would seem best to
require the DSS client to explcityl call out which sub-profile was in
effect.

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

But we don't want different concrete profiles defining unique switching
mechanisms. The URI should be the flag.

>
>
>Trevor 
>