SPML Use Cases: Emergency Response and Attribute Service focused...

["John, Anil" <Anil.John@jhuapl.edu>]

All,

I thought I would take a shot at describing what the SPML needs and use cases we are running into in the public sector work we are doing. There are some things that we are working on that I have permission to use organization names (given that I've already talked about them in external presentations) and others for which we have not gone through the public release process, and as such will deliberately be generic.

Please know that for us, SPML is a means to an end, and our focus is around the management and movement of attributes that will typically be used in Logical Access Control Systems (LACS) and Physical Access Control Systems (LACS) for Attribute Based Access Control.

1) Emergency Response Case 1

If you look at the National Response Framework @ http://www.fema.gov/emergency/nrf/ and the Emergency Support Function Annexes that are found there, you will note that Emergency Response Officials, whether in the Federal Government or State/Local/Tribal arena, are assigned certain specific attributes that call out their responsibilities. Typically this is NOT done in a top down manner, but is left up to individual organizations to assign the attributes to their Emergency Response Officials, and this information is kept within their own systems.

But in order to coordinate the response to a disaster, those organizations (particularly at the Federal level) are required to provide information about those officials and their particular attributes to a repository that is managed and maintained by a central organization.  It would behoove this repository to expose a standardized and open interface such that the provisioning of the users and their attributes, from their home organizations, takes place in a standardized and automated manner that leveraging existing tooling. It is assumed that network connectivity exists between the interface and the "clients" that need to talk with it. This interface would need to support the following characteristics:

   * The ability to do CRUD operations
   * The ability to do batch CRUD operations
   * The ability to advertise supported operations that can be performed on the interface via metadata
   * Support for layering in standardized cross-cutting security processing on the message exchanges (typically SOAP/WS-Security)


2) Emergency Response Case 2

This is the other side of the picture. Now that we have the attributes in the repository, how can they be leveraged in a mobile and potentially comms-out (communications infrastructure is not available) environment? This typically requires the ability to bring "down" the attributes into some sort of mobile device that may or may not have real-time network access so that it can be taken on site in the case of disasters.  As such the interface is more of a "synchronization" and/or "get/refresh" from the client's perspective. This interface would need to support the following characteristics:

   * The ability to GET attributes
   * The ability to obtain UPDATES to data that exists locally on the mobile platform

3) SPML Operations on an Attribute Service

This use case was something that was described in a presentation I gave at Gartner/Burton Group Catalyst this summer on the the Federal ICAM Backend Attribute Exchange (BAE).  The BAE interface supports both a SAML Attribute Query Interface as well as a set of SPML operations for "batch pull" capabilities.  The reason for the existence of the SPML operations is that a SAML Attribute Query is not able to answer the following questions:

   * "Give me the unique id's of all users with Attribute X"
   * "For all users (whose unique id's I just got), give me listing of attributes for each (in one shot)"


The way forward for us was to focus on a very simple set of SPML operations that included:

   * search (needs to be restricted and described via metadata)
   * lookup
   * batch

The problem as it exists is the following:
- search operations are pretty unbounded and there does not exist a way for me to advertise "what is permitted on which attributes" as part of the SAML 2 Metadata I am exposing
- by implementing just these three operations I am no longer "SPML v2 compliant"

So what we are looking for is a "Read Only" profile for SPML that does just that. 

Finally and just as important, we would be very interested in how SAML 2 Metadata can be used/extended to advertise SPML Operations. From the Attribute Service perspective we have profiled SAML 2 Metadata to be able to advertise an Attribute Services' capabilities (Unique identifier, Certs used, endpoints, supported subject identifier types, supported attributes, contact info etc) and as such would like to leverage what already exists instead of creating something new for SPML.

Would be glad to answer any questions.

Regards,

- Anil


:-
:- Anil John
:- Johns Hopkins University - APL
:- http://www.jhuapl.edu
:- +1 240.228.0612
:-
:- E-Mail Response Time: 24 hrs