RE: [dss] Finalizing core spec

["Nick Pope" <pope@secstan.com>]

Trevor,

See below:

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 13 April 2004 20:54
> To: Nick Pope; dss@lists.oasis-open.org
> Subject: RE: [dss] Finalizing core spec
>
>
>
> Hi Nick, all,
>
> Let me summarize what I think is the consensus, and where we need more
> discussion.
>
> Hopefully we can finish these off in the next day or two, and get
> a new draft.
>
>
> At 11:44 AM 4/13/2004 +0100, Nick Pope wrote:
> > >
> > > 1) Since we've decided to handle Async support in a profile, should we
> > > remove TryAgainLater?  Or allow profiles to introduce new ResultMajor
> > > codes?  Or just leave it as is?
> >
> >I would be interested to get Andreas' view, but I would suggest that
> >ResultMajor should not be restricted to those value given in the
> standard to
> >allow flexibility for the asynch profile to define other return values.
>
> Andreas agrees, I do too, so the tentative consensus is:
>   - Remove TryAgainLater
>   - Allow profiles to add new ResultMajor codes
>

OK
>
> > > 2) Andreas has proposed the client could indicate multiple
> > > profile URIs in
> > > a request (i.e the client could say "the WSS *and* German Sig-Law
> > > profiles
> > > are in effect).  See this thread:
> > > http://lists.oasis-open.org/archives/dss/200404/msg00019.html
> >
> >I agree
>
> I disagree, I think it'll be confusing to have multiple profiles
> in effect,
> since they'll likely have clashing requirements.
>
> However, the tentative consensus is in favor of this (you and
> Andreas).  I'd like to see a concrete proposal - right now the
> 'Profile' is
> indicated as an attribute, perhaps we would add an "AdditionalProfile"
> optional input that could occur multiple times?  What happens if
> requirements conflict?
>

This is a useful way of signalling the addition of horizontal functions.
For example, code signing with policy wise, or code signing with asynch, or
code signing with asynch and policy wise.  Clearly there will be some
combinations that do not make sense.  However, if someone wanted to do
something I think is stupid then I have no problem allowing him to do it (it
may even turn out to be not so stupid).  When defining a concrete profile
the other profiles that make sense to be used in combination can be
identified.  If it is not an "approved" combination then the "caveat emptor"
rule can apply.

I suggest that we put in a warning in the Core that the results may be
unpredictable if there are conflicts between the profiles selected.

It may make more sense to have "Profile" and "AdditionalProfile" as Elements
of the SignedRequest rather than attributes.

BTW I noted an error that 2.8.1 refers to a ServiceProfile attribute whereas
3.1 and 4.1 use the attribute Profile.



>
> >One other minor change in 4.5.7 when updating a signature the attribute
> >"Type" is used to identify the type/form of updated signature
> required.  In
> >the XAdES profile, and the Core, "SignatureType" is used to identify the
> >basic type of signature (CMS, XMLSig, Timestamp).  SignatureForm
> is used to
> >identify the different forms (ES-T, BES etc).
> >
> >I suggest that in element "ReturnUpdatedSignature" we rename the
> attribute
> >"type" to be "Form".
>
> I'd rather stick with the generic term 'Type'.  'Form' is specific to the
> XAdES profile.  We use 'Type' in a few other places for parameterizing
> elements (AddTimestamp, Base64Signature, DetailType), and
> XML-DSIG uses it
> as well.

I'm not too concerned about this.

Nick