RE: [dss] Core versus Extended Profile Handling

["Edward Shallow" <ed.shallow@rogers.com>]

Yes, I inderstand. Thanks

Rich wrote "If instead A and B are elements that appear in the
defined-in-core ..."

Yes exactly. I had thought of that casually, but dismissed the concern based
on the assertion that if things start getting shared across profiles, they
belong in the core. This eliminates the multiple inheritance anomaly.

This brings us full circle to the core versus extended profile delineation
challenge. I saw profiles has having to salute and respect the core only.
Any borrowing or re-use of other profiles is entirely unofficial. 

For example, the EPM profile, apart from implementing its own extensions,
may find the "Corporate Seal" facility interseting enough to offer it. Until
the structures of the "Corporate Seal" make there way into the core schema,
a profile is free to do what it pleases as long as it respects the core.
Clearly opportunities for alignment will start to emerge, and the DSS can
decide over time to include these commonly shared constructs in the core
schema. Until then, the profiles can unofficially respect the other
published profiles as much and to the extent they can. 

My real motives for expressing things for explictly (and less nebulously)
stems from a desire to reduce implementation complexities for our clients.
The DSS protocol is really more of a usage and subscription service protocol
or an RPC-like dialog, with things like requests, options on requests, and
responses. This unlike the static nature of XMLDSIG which defines content
representation only, and not service consumption approaches like DSS (and
the EPM) does. Hence we have a greater challenge than to the content
protocol families.

Invariably DSS will be bound to underlying SOAP layers and implementors will
expose their DSS-compliant services via WSDLs. Implementors will publish
these WSDLs and allow their customers to generate client calling stubs using
WSDL stub generators (i.e. WSDL-2-Java, WSDL-2-DotNet, etc ...)

We have taken great pains to ensure our WSDL can be used to create
consumption stubs using the most popular generators including IBM's WSTK,
Sun's Jax-RPC, TME's Glue, MS's .Net, etc ... My point is that these
generators do not repsond well to vagueness (e.g. choice, any, etc ...) They
are generating language-specific object representations of the WSDL (and
underlying schema) constructs.

Thus any steps we can take to define our core and our profile with greater
precision and specificity, the esaier it will be for our clients to consume
our services.

Finally, what is the team's stance on the first few profiles they have
identified for co-publishing next July. If they have all their optional
types and constructs published in the core they are not really profiles
anymore, they are actually supported. If a profile has everything it needs
to proceed with implementation and need only define normative rules and
usage examples, I don't call that a profile.

My innocent assumption was more along the lines that a profile is really and
truly an extension.

Perhaps we have both here ? Usage profiles supported by the schema AND
extended profiles which stretch the schema ? Comments ?

Ed      

-----Original Message-----
From: Rich Salz [mailto:rsalz@datapower.com] 
Sent: November 6, 2003 1:14 AM
To: Edward Shallow
Cc: dss@lists.oasis-open.org
Subject: RE: [dss] Core versus Extended Profile Handling

>    I'm not sure I see the "feature-mixing" problem. Sorry. Perhaps an 
> example would help. If an additional option in a new profile requires 
> an additional request type and an additonal response type ... no 
> problem. If a profile requires several new features, presumably driven 
> by new options on our primitives, then either existing, extensions on 
> existing, or entirely new type structures must be introduced to 
> support the new features. Each profile extends only the core.

It's like multiple inheritance.

Suppose profile "A" extends the sign operation to add an Expiration element
-- some special information that results in a signature only being valid for
a certain time period.  Suppose profile "B" extends the sign operation to
add an EncryptFor element -- the signature is encrypted so that only certain
folks can read it.

Suppose I want to do encrypted expiring signatures.  I have to define a
whole new profile that defines how to combine A and B into a new request
element.  If more options get defined, we end up with a combinatorial
explosion of profiles.

If I present any of A, B, or A+B to a "classic" DSS server, that server will
just have to say that it doesn't recognize the request.  It would be better
if the server could respond "Option A not supported" but it can't do that.
If my A+B server wants to support A,B,A+B, then it has to recognize three
different URI's for the three different sign operations.

If instead A and B are elements that appear in the defined-in-core Options
container, then all these problems are avoided.

Make sense?
        /r$
--
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html


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
.