RE: [dss] Core versus Extended Profile Handling

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

Ed, Rich, Trevor,

Catching up on this thread, there is one point that I would like to add:

If we find option/output elements that are common, or likely to be common,
to several profiles before the DSS core is published, I would suggest that
the schema definition of those option elements is placed within the core
specification thereby maximising commonality.  I agree, however, this should
not be mandated, and there will be situations where one profile may inherit
an element from another profile's namespace.

Nick

...



<ed>They don't get complicated until the implementation decides it now wants
to be compliant with the uprev, which it is not obliged to do. </ed>

Also, I don't believe that just because 'n' profiles want the same element,
that the core must be changed.

<ed>I agree, they can stay within the comfort of the profile
indefinitely.</ed>

> Until then, the profiles can unofficially respect the other published
> profiles as much and to the extent they can.

If A wants to use B's profile, then A must define its own element and
include the set of (B-core) in A.

<ed> And so ? If a B profile's features and capabilities are so attractive,
they should be scoped into DSS from the beginning. If not, they are simply
good examples of how to do things.</ed>

It fits what X509 does, DSIG does, etc.

<ed>Not a fair comparison, as I said earlier, DSS is a request/response
protocol wedged in between a slew of existing well-established content and
binding standards (i.e. XMLDSIG, PKCS7/CMS, SOAP) not to mention all the
others we are treading so close to. Let's face it DSS is a lot closer to the
implementation and consumption side of the spectrum than something like a
signature layout standard. Staying nebulous will not help with its take-up
and acceptance, which is really fundamentally addressing a "How do I ask for
a signature ?" question and hence a "rubber meets the road" challenge.</ed>


> My real motives for expressing things for explictly (and less
> nebulously) stems from a desire to reduce implementation complexities for
our clients.

Seems that having a single request, where additional elements get stuffed is
a lot simpler than having to know about (several) different namespaces for
different requests.

<ed>It is not obligatory to know or follow or emulate anything that stays in
the recesses of a profile.</ed>

I understand your desire in making it simple to map this into native
object-model RPC.

<ed>That is because that is all DSS is !!! A signature creation and
verification request mechanism.</ed>

I don't share the desire.  Or rather, I see that as less important than
getting a real extensible protocol specified.

<ed>The thinness and therefore value of what is left is scary to me.</ed>

And implementations that want to do this can always write a "custom" WSDL
that fills in some of the spaces in the Options element.

<ed>I thought this was exactly what we were trying to make easy ?</ed>

I'll try to be productive in closing ...

I believe DSS implementors must see value in what is produced and shouldn't
be too constrained in how they salute and extend the spec.
I therefore vote for extensibility option "C", totally separate schemas
which import and ref from the base dss schema and extend as they chose.
Clearly there will be less divergence the more one "specifies" in a
non-nebulous way the details of the core.
Perhaps one can look at this as a compromise.

Ed



To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php
.