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.”