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
