[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] CA will be participating in the SPML v2 Interoperability Event - A few question (Looking for Responses) are inline in the message
**
Posting on behalf of CA Development Team** - Look for some responses… Thank you very much for
explaining, Jeff. Could you please see inline for my further comments? Regards, Van Bui eTrust, Computer
Associates -----Original Message----- CA will be participating in the SPML
v2 Interoperability Event ** Posting on
behalf of CA Development Team** - Look for some responses… Hi all, Our team recently began working on
migrating some of the components in the Computer Associates eTrust IAM Suite
from SPML V1 to supporting the V2 of the specification. We would be very
interested in participating in the upcoming Interop event by providing both an
RA and PSP. I have some questions from beginning to
work with the V2 specification that do not seem especially clear at this stage.
Is anyone able to shed some light on them? 1. I gather that with the open content model, a requestor or a provider
can specify additional operational attributes when issuing and responding to
SPML requests via the “any” elements. Similarly, we can store any
implementation specific metadata information about the DSML attributes, assuming
that the provisioning schema is represented in the DSMLv2 Profile schema, in
the “any” elements. But IMHO, the “permission”
metadata, which can be set to either read-only, write-only, or read-write, is a
common and useful metadata information that can be included as an optional
attribute of an <dsmlprofile:attributeDefinitionReference> element. What
do you think? [JSB] The
problem is that in some cases the “permission” is not part of the
metadata but is part of policies with respect to the identity of the requestor.
In other words an attribute may be read-only to a client with one set of
permissions but be read-write to a client is a different set. [Van]
I
wasn’t thinking about those attributes that were access-controlled by
some policy. I was thinking about the scenarios where the
“permission” is a static metadata, for example:
If
this information is made available in the provisioning schema then each client
won’t need to have local knowledge about how to deal with the data.
However, as I said, “permission” and other metadata information can
always be set via the open content model – so this issue can now be
closed. 2. Is there a way for a provider to declare that it only supports a
selected number of operations in one of the standard capabilities? [JSB] No. It
is assumed such cases are handled by exception rather than declaration. 3. Why does an AddRequest have a separated “targetID” and
“containerID” field while these fields are capable of being set as
part of the “psoID”? [JSB] SPML 2.0
supports both flat and hierarchical data models. If a hierarchical data model
is used, then a new PSO can be added to the root target or to an existing
container. Since the container specifies the target it exists on, the add
request can specify either the target or the container. [Van]
Section
3.2.3 of the draft 10 of the specification states that a "PSO Identifier
must be unique [snip] within the namespace of the provider", which I've
interpreted as "A valid PSO Identifier must uniquely identify an object
managed by the provider". For hierarchical targets, this is achieved by
combining the targetID, containerID, and the object's ID in a PSO Identifier.
This leads me to think that the targetID and containerID in an AddRequest are
extraneous. For the same reason, it is not necessary to include a separate
targetID field in a SearchQueryType because this can be set as part of the
basePsoID. If
I've misunderstood and there is indeed a need for being able to specify
targetID, containerID, as well as psoID in an AddRequest then shouldn't this
also be applied for the Modify, Delete, Lookup requests, and all the different
request types of the Suspend, Active capabilities? (As of draft 24 of the XSDs,
one can only set the psoID fields for these requests). 4. The “modificationMode” attribute of an
<spmlcore:modification> element at the moment doesn’t have a
default value. Should the default it to “replace”-mode to make
things clearer? [JSB] There
should be a default. Replace would seem to be the logical choice. 5. Do you think that there should be a standard way for the requestor
to request the provider to return the list of affected PSO’s when
performing a bulkModify or a bulkDelete operation? The Add and Modify
operations already support this. [JSB] Such a
mechanism already exists. Simply supply the same search query in a search
request, specifying that only the PSO ID should be returned. That would return
the list of PSO IDs that would be affected by the appropriate bulk operation.
This of course assumes the service that supports the bulk capability also
supports the search capability. [Van]
After
the search request was performed and before the bulk operation is processed,
there is always the possibility that the target (system) might be modified
externally by a different requestor, therefore, the list of PSOs returned from
the search request might not reflect accurately what would actually be affected by the bulk operation. 6. How do I store the list of sub-requests in a BatchRequest? I
can’t see it in the new Schema. [JSB] The
sub-request for a batch operation are included via the open content model. See the
SPML 2.0 Specification document for examples. [Van]
Do
you think it is more restrictive and is at the same time easier to use
(compared with using the open content model) if it was explicitly specified
that a BatchRequest can contain:
<element name="batchRequests" type="spml:RequestType"
minOccurs="1" maxOccurs="unbounded"/> …and
a BatchResponse can contain:
<element name="batchResponses" type="spml:ResponseType"
minOccurs="1" maxOccurs="unbounded"/> 7. The Updates Capability seems like a useful operation, and there is
an XSD for it, but there is no mention about it in the draft 9 of the
specifications, can someone please explain why? [JSB] That is
an oversight. Thank you for pointing it out. I will touch base with By the way, we are using draft 24 of the
XSD. Thanks for your help. Van Bui eTrust, Computer Associates |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]