There are really two kinds of attributes at issue; 1) the attributes on the provisioning data (accounts, groups, etc), and 2) attributes on the provisioning protocol (request ID, etc). They are separate issues.
1) For the provisioning attributes you can absolutely determine which attributes are mandatory. The provisioning client can query the provisioning service for the provisioning schema. The provisioning schema is defined in a profile specific manner. For SPML 2.0 there are two profiles defined, the DSMLv2 Profile and the XSD Profile. In the DSMLv2 Profile the provisioning schema is using an attribute/value definition syntax that is part of the profile. In the XSD Profile the provisioning schema is defined using XSD. Both profiles support defining mandatory attributes. As would any future profiles that would be defined for areas such as federated provisioning.
2) For the attributes on the provisioning protocol itself there are normative definitions for their use (when they mandatory and when they are not). For instance the Request ID (which is a concern for HP) is mandatory if the request is asynchronous, or if it is a synchronous request being passed over an asynchronous protocol. HP would like the Request ID to be mandatory to satisfy requirements outside the bounds of what the PS TC decided was in scope.
I hope that clears it up.
Jeff Bohren
BMC
-----Original Message-----
From: Andrea Westerinen (andreaw)
[mailto:andreaw@cisco.com]
Sent: Monday, May 23, 2005 6:18 PM
To: Bohren, Jeffrey; provision@lists.oasis-open.org
Subject: RE: [provision] HP
Comments on SPML 2.0...
Jeffrey and James, How do you have any interoperability if you can't decide on mandatory/optional? This seems broken to me.
Andrea Westerinen (lurking)
From: Bohren, Jeffrey [mailto:Jeff_Bohren@bmc.com]
Sent: Monday, May 23, 2005 11:20 AM
To: provision@lists.oasis-open.org
Subject: [provision] HP Comments on SPML 2.0...James Hu from HP send me some comments about SPML 2.0 and asked that I forward them to the list. James wrote:
“I think our concern is about the lack in capabilities of transaction and orchestration among multiple resources/targets. Both of these are critical part of federated identity management. Without this in standard, one has to add extension to support these features. For example, to hold transaction context, I can add transaction capability as suggested in the 2.0 spec and can also add a federation capability as schema extension for request correlation context. However, it seems that the current spec does not provide means to effectively describe the extension capability details for RA to introspect. Without being able to expose this meta information as contract between RA and PSP, any extension capabilities have to be restricted to local environment in which RA has priori knowledge about PSP and is therefore not interoperable. Please correct me if I'm wrong here.
Current 2.0 draft allows RA to query meta information for PST ( e.g listTargetRequest ) but not PSP. Exposing PSP level meta data could enable RA to introspect additional information for some part of schema. For example, I realized that the requestId is currently an optional attribute but in some Identity Management systems, requestId must be 'required' ( required in our product ). We then have to add schema extension to make it 'required' but that will make it not interoperable. If the PSP can expose some PSP level meta data for RA to introspect whether the attribute is required or optional. then a single attribute in the standard can be used either as 'required' or 'optional'. Given this, for all the attributes that can be either required or optional depending on PSP, the standard may always denote them as optional ( as default ) but allow PSP to alter them at runtime.
Another concern is target schema exposing. In some Identity Management system like we have, data structure in target is not directly exposed to RA and the abstraction is provided to hide the physical data schema. RA thus always sees name value pair in most of cases instead of physical data structure. The spec should provide an option to let RA know during the introspection phase that the schema for identity attributes are simply in name value pair format ( similar to what was in SPML 1.0 ) . I think we can simply expose a generic name-value pair schema in listTarget request but it needs additional means to indicate that this is a special schema.”
Jeff Bohren
13577 Feather Sound Drive, Suite 200, Clearwater, FL 33762
tel: 727.561.9500 x219
fax: 727.374.0171
