RE: [dss] Core versus Extended Profile Handling

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

John,

Interesting thought. Certainly, worth baring in mind.

Nick

-----Original Message-----
From: jmessing [mailto:jmessing@law-on-line.com]
Sent: 08 November 2003 17:12
To: Edward Shallow; 'Rich Salz'; Nick Pope
Cc: dss@lists.oasis-open.org
Subject: RE: [dss] Core versus Extended Profile Handling


It seems from the descriptions that the DSS standard will be an API that is
divided by agreement into what is standardized as core and thus not likely
to be appropriated as claimed proprietary patent or trade secret technology,
and the remainder which is not subject to that restriction as profile, which
can be open or not.

If that distinction is correct, then the inheritance described by Nick
between profiles could inadvertently create a licensing requirement between
A and B in order for the inheritance to occur legally. Is that the kind of
practical consideration we want to factor into the work of the TC?

---------- Original Message ----------------------------------
From: "Nick Pope" <pope@secstan.com>
Date:  Sat, 8 Nov 2003 15:39:17 -0000

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

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
.