NISS Knowledge Base

Justice Information Sharing

gonin / shutterstock.com (see reuse policy).

FAQs

The table below addresses roles and responsibilities from a GFIPM Technical standpoint.

GFIPM Technical Roles and Responsibilities
*Role*	*Responsibilities*
Certificate Authority (CA)	1. Sign cryptographic certificates for member systems. 2. Sign the GFIPM Cryptographic Trust Fabric document. 3. Distribute the GFIPM Cryptographic Trust Fabric document to all member organizations.
Identity Provider (IDP)	1. Perform authentication for end users. 2. Generate SAML assertions containing GFIPM metadata about users. 3. Conform to the GFIPM Web Browser User-to-System Profile.
SAML Service Provider (SP)¹	1. Provide Web-based access to application-level services for end users. 2. Enforce resource access control policies based on GFIPM metadata from IDPs. 3. Conform to the GFIPM Web Browser User-to-System Profile.
Web Service Consumer (WSC)	1. Provide a connecting point through which a member organization can connect to GFIPM Web Services providers (WSPs). 2. Conform to the GFIPM Web Services System-to-System Profile.
Web Service Provider (WSP)	1. Provide Web Services-based access to application-level services for member organizations and their end users. 2. Conform to the GFIPM Web Services System-to-System Profile.
Authorization Service (AS)	1. Make authorization decisions on behalf of other GFIPM Web Services providers (WSPs) and issue tokens that can be used at those WSPs. 2. Conform to the GFIPM Web Services System-to-System Profile.
Validation Service (VS)	1. Provide validation of tokens, including GFIPM User Assertions, on behalf of other GFIPM Web Services providers (WSPs). 2. Conform to the GFIPM Web Services System-to-System Profile.
Trusted Identity Broker (TIB)	1. Generate SAML assertions containing GFIPM metadata about users from brokered IDPs. 2. Conform to the GFIPM Web Browser User-to-System Profile.

The Global Reference Architecture (GRA) addresses various areas in the implementation of information exchange. Together, these areas form critical components of a comprehensive, replicable, and scalable solution to information sharing that balances varied technologies with dynamic policy considerations:

Reference Architecture Planning
The GRA includes recommendations for technical implementation that leverage Service Oriented Architecture concepts, customized for the justice domain. GRA addresses the full range of information sharing use cases by providing a flexible blueprint for implementing interoperable data sharing services across both technologically advanced organizations and those with limited technology resources. Guidelines for beginning implementation projects are available.

Service Specification Packages
GRA solutions to information exchange are made up of a combination of the connection method (often Web Services), the exchange language (use of NIEM is encouraged), and the security specifications (encryption at the transport layer, data layer, etc.). These specifications are packaged into a GRA solution that can be customized to meet an individual organization’s needs. A repository of Reference Service Specification Packages (SSPs) for information exchange in the justice community is being established; however, individual Reference SSPs are available in the interim.

Technical Implementation Guidance
Integrating a Reference Service Specifications Package (SSP) into existing IT infrastructure, despite the level of customization available in a Reference SSP, can involve a learning curve for those new to the implementation of GRA. Technical guidance regarding the GRA specification itself, as well as various guides on the interaction of different services and other aspects of information exchange, are available. In addition, personal assistance in implementing GRA is available through a number of valuable resources. See the Implementation Assistance section for more information.

Policy Guidance
In coordination with the technical implementation of a GRA Reference Service Specification Package, policy-level documents guide interaction between the agencies exchanging information. Examples include Service Level Agreements (SLA), access and identity management specifications, Memoranda of Understanding (MOUs), and many others. While these documents are never specific to GRA implementations, some specific resources available may be helpful in policy agreements. Source:

Source: https://bja.ojp.gov/program/it/national-initiatives/gra

The IEPD Clearinghouse is a Bureau of Justice Assistance (BJA) sponsored initiative developed and supported by the Global Justice XML Data Model (GJXDM) Training and Technical Assistance Committee (GTTAC) and the IJIS Institute.

The Information Exchange Package Documentation (IEPD) Clearinghouse is a website that empowers government and industry IT professionals with information about planned, in-progress, and completed IEPD initiatives.

Public and private developers can maximize resources and time by using the IEPD Clearinghouse to gain access to Global Justice XML Data Model (GJXDM) and National Information Exchange Model (NIEM) conformant and reusable artifacts. Funding agencies, policy makers, and managers can avoid duplicative efforts by researching in-progress IEPD development initiatives. Most importantly, the IEPD Clearinghouse enables directly relevant collaboration between organizations and people working to solve similar problems within the justice and public safety community

What is an IEPD?

An IEPD is a collection of developer-originated artifacts that promote reuse and enable wider adoption of standards. These artifacts include data exchange and domain models as well as GJXDM- or NIEM-conformant data maps and XML schemas. Reuse of these IEPD artifacts allows developers to focus on local adaptation through extensions and refining or enhancing the global baseline.

IEPD Clearinghouse Benefits & Features

Enables search for information about planned, developed, or implemented IEPDs
Allows organizations to share IEPD information
Provides links to real-world, reusable IEPD artifacts
Accelerates the design & development processes
Promotes utilizing the Global Justice XML Data Model (GJXDM) and the National Information Exchange Model (NIEM)

IEPD Clearinghouse Access

The IEPD Clearinghouse is an interactive repository containing updated information about IEPDs that can be accessed via https://bja.ojp.gov/program/it/niss

Submitting IEPD Information to the Clearinghouse

In only a few minutes, a user can submit information about IEPDs to the Clearinghouse by downloading and completing the IEPD submission form and creating a user account.

IEPD Clearinghouse Support

For IEPD Clearinghouse inquiries or support, please contact the National Information Sharing Standards (NISS) Help Desk via:

Web https://bja.ojp.gov/program/it/niss

Telephone 1-877-333-5111 or 703-726-1919

E-mail [email protected]

Practitioners and industry organizations are defining “reference” information exchange models for specific business needs to reduce arbitrary variations and promote interoperability at the Information Exchange Package level.

GJXDM and NIEM provide a set of defined data and an object structure for that data. However, the models do not define sets of data for particular business information exchanges.

Without the IEPD, there would be no agreement on which GJXDM or NIEM properties (and extended properties) are used or how they are structured within the IEPD. Given the same set of business data requirements, each implementing organization could develop a different IEP to represent that same set of business data. Even if the IEP from a particular sending organization could be interpreted, it would be expensive for organizations to handle the IEP variations from the different senders.

By developing and reaching agreement on the IEPD for an information exchange within a particular enterprise, participants can send an IEP that can be understood by those receiving the IEP whether it’s within the state, county, or nationally.

If Reference IEPD for an Incident Report is developed and recognized by a nationally respected organization, states are more likely to use that Reference Incident Report IEPD as a model for developing their state-specific Incident Report IEP. This minimizes unnecessary differences from state to state while still enabling each state to tailor the Incident Report IEPD to meet state-specific business needs. It may be that the Reference Incident Report IEPD is inclusive enough that it can be used as-is for a particular state. The state-specific Incident Report IEPD would be used to exchange incident information between different jurisdictions within the state or between a jurisdiction and the state repository.

Carrying this concept further down, a county-wide enterprise could use the state Incident Report IEPD as a reference model to develop the IEPD for an Incident Report meeting the specific business needs of the county. This county-specific Incident Report IEPD would be used to exchange incident information between different organizations within the county.

Continuing with this concept going up, the Reference IEPD for an Incident Report could be used as-is at the national enterprise level for exchanging incident information between states or between states and the federal government.

The benefit of this consistency is that organizations implementing information exchanges can more quickly and cost-effectively deploy them across multiple jurisdictions at all levels. IEPD (and Reference IEPD) takes the benefits of using GJXDM and NIEM to a higher level. Ultimately, organizations implement information exchanges based on IEPD, not on GJXDM or NIEM.

GJXDM IEPD Guidelines: https://it.ojp.gov/topic.jsp?topic_id=196

NIEM IEPD Guidelines: https://www.niem.gov/training/Documents/Mod08_NIEM_PI_IEPD_Concepts.pdf

How many message sets should one IEPD cover:
1) A single message, a portion of a set;
2) A single message set, a single exchange from start to end;
3) Many message sets?
What is the impact of placing to many or to few message sets in an IEPD?

There is no guidance at this point as to how many exchanges an IEPD should cover.
In fact, PMO is in the process of refining an IEPD specification, so some of this may be subject to change in the future.

That said, the concept of an IEPD is meant to be simple and scalable. If I create an IEPD for a set of related exchanges (or message payloads) like a set of queries and associated responses, and they all use the same subset and extension schemas, then it's probably a good idea to put them all into a single IEPD with a name that embodies the business purpose or function of these queries/responses. If I have a fairly large exchange (such as a Rap Sheet or a SAR) then it's probably better to keep that by itself in a single IEPD. If some kind of small query goes with that exchange (to trigger it or request it), then it's probably a good idea to keep that in that IEPD as well. The user must decide how cohesive a set of exchanges are. The more cohesive a set of exchanges are (either from a business perspective, functional perspective, or possibly organizational perspective, the more likely they should be together in one IEPD, especially if they employ/share the same subset and extension schemas.

The impact of too many or too few? As far as we know, there is no answer to this question. Again, the IEPD concept is meant to be simple. Does it simplify usability and understanding to combine exchanges into a single IEPD with one set of documentation? Are the exchanges fairly cohesive and depend on the same subset and extension schemas? Will creating a single large IEPD (with many exchanges) be more confusing or less confusing than making each a separate IEPD (possibly with lineage)? These are the kinds of questions a developer must answer to determine the best approach.

Occasionally, you may find yourself needing a wantlist that does not exist. This typically occurs when dealing with older IEPDs from the GJXDM era.

Why you might need the wantlist?

1) You need to make modifications to GJXDM subset schemas. The SSGT cannot import subset schemas. Instead, it needs a wantlist. If you have the subset schemas but no wantlist, then you can't modify the subset schemas with the SSGT.

2) You need to migrate a GJXDM IEPD to the NIEM. The NIEM Migration Tool requires a wantlist from which to migrate. Again, if you only have the subset schemas, you can't use the tool.

A quick aside here: If your problem is that you have a GJXDM 3.0 or 3.0.2 wantlist and see that the Migration Tool only supports GJXDM 3.0.3 wantlists, the solution is simple. Open the wantlist file in a text or XML editor and simply change the version number to 3.0.3. Because GJXDM 3.x versions are backwards compatible, earlier versioned wantlists cannot have anything in them that isn't also in version 3.0.3. So you can safely rename the version and use that for migration.

Why is it missing?

In many cases, the wantlist doesn't exist simply because the IEPD predates the advent of wantlists in the Subset Schema Generation Tool (SSGT). The SSGT initially had no way of saving a partially completed subset. Wantlists were originally a means for a user to save their place. The wantlists themselves later became the standard for listing needed elements and types.

In other cases, the subset schemas may have been created in tools other than the SSGT, which may not have also produced a wantlist.

Additionally, some subset schemas were actually created by hand, in standard XML editors, or even in text editors.

Finally, there may have once been a wantlist at the time subset schemas were created for an IEPD, and yet it may have been omitted from a published IEPD through neglect or oversight.

What to do about it?

There are a few alternatives. The first one is to simply re-select all the elements in the SSGT. In the case of a minimal exchange, this may be the simplest method. In other cases, this will be a long and tedious process.

Another alternative is to create a tool to read the subset schemas and produce a wantlist. The format for wantlists is standardized and publicly available. It is also fairly simple. XSLT would be an good basis for such a tool.

A final alternative is to find someone who has already created such a tool. One example is gotWantlist, a whimsically named tool hacked together quickly to create wantlists while migrating some very old GJXDM IEPDs.

As an admitted hack, gotWantlist comes with a laundry list of requirements and caveats.

Firstly, gotWantlist is written in PHP5, so PHP5 must be installed, either locally or on a web server somewhere. The code can either be run from the command line, directing the output into a file. Or it can be saved on a web server somewhere and run via a browser, saving the output as plain text.

Using gotWantlist requires a small bit of preparation. Here are the steps:

1) Save your GJXDM subset somewhere. (Really, all you need is the "3.0.2/jxdm.xsd" file.)

2) Put gotWantlist.php in the "jxdm" directory for the subset.

3) Open "jxdm.xsd" in a text editor and delete all the "xsd:" occurrences. It's just a simple search and replace. Save it as "f-jxdm.xsd". The reason is that the code was a quick hack using PHP's SimpleXML parsing, which was choking on namespaces. This workaround was faster than trying to figure out the namespace problem.

4) Run gotWantlist.php. It'll parse through "f-jxdm.xsd" and output a wantlist to standard output.

gotWantlist is GPLed. Feel free to use it or share it within the confines of the GPL. The code comes with absolutely no guarantee of any kind.

The code can be obtained from the NISS Helpdesk.

An XML parser is the piece of software that reads XML files and makes the information from those files available to applications and programming languages, usually through a known interface like the DOM. The XML parser is responsible for testing whether a document is well-formed and, if given a DTD or XML schema, it will also check for validity (i.e., it determines if the document follows the rules of the DTD or schema). It is a programming library that improves programmers' access to the contents of an XML document. There are two main categories of XML parsers: Document Object Model (DOM) parsers, and Simple API for XML (SAX) parsers. DOM parsers take the approach of creating an in-memory representation of the XML document, which the developer can then "walk" to find the information desired. SAX parsers take a different approach that does not store the entire document in memory; rather, as elements are encountered in the XML document, an event is generated to inform the programmer's code of the fact. The programmer's code then does whatever is appropriate at that point in the document.

Other tools, like XSLT transform engines and XML-object binding toolkits, are built on top of XML parsers and offer enhanced functionality in processing XML.

All parsers will produce parse errors upon encountering non-well-formed XML. Many parsers will also validate the XML instance against a schema, if one is available. (Often this requires setting an option on the parser before parsing takes place.)

Most development platforms and programming languages have at least one XML parser available. XML parsing capabilities are built-in to the Java and Microsoft .NET platforms. In Java, the programmer can use the default library that ships with the Java 2 Standard Edition (J2SE) environment; alternatively, the programmer can "plug in" any compliant parser, such as the Xerces parser from the Apache Foundation.

The alternative to using a parser is to program the processing of an XML document "by hand" (i.e., by reading the XML text, processing XML tags, etc.) While seemingly an easy task, implementing the full XML specification (in addition to schema validation) is complicated. Absent a very good reason, developers should use an off-the-shelf XML parser.

In the instance when two different sub-schemas are created with the subset generation tool, and data in the XML instances of these schemas is dynamic and manipulated extensively, XMLBeans 1.0.3 should be used for Java-XML Binding. XMLBeans is a great light-weight framework that creates an object model of XML schemas. When a schema is ''compiled,'' the XMLBeans schema compiler generates the source code and classes, as well as schema snippets. By default, the code and classes are stored in packages that are derived using the namespaces provided within the schema, which can be very convenient.

However, there is a major downside. The whole reason for the subset generation tool is to provide a way to create a schema that contains only the types, elements, and attributes that are needed. Which means it is possible, and quite likely, the similar types between schemas will be different. For example, the ArrestType in one schema may contain an ArrestCharge element, where as the ArrestType may not have that element defined in different schema. The typical XSL transformation is not sufficient.

When moving and manipulating data between instances of these two schemas programmatically, driven by rules, JAX-B makes sense (for example, if similar types are defined in the schemas which differ in structure.) The namespace for the classes is the same. At runtime, the Class loader will search the class path for class definitions. When the class loader finds a class definition for the class requested, qualified by its namespace or package name, it loads it into the Java Virtual Machine (JVM) and allows the program to use it. The question is, "Which definition of ArrestType did the loader find?" There are two ways to solve the problem. First, one could generate an XMLBeans model for the entire GJXDM or NIEM, and use that library for deployment at runtime. There are pluses and minuses. The upside: one does not have to worry about having all the methods available at runtime. The object will support all of them. The downside(s): Who wants to see ''all'' of the available methods while developing the code? And, there is a bit of a performance hit as the JVM scans the library for ClassDefs.

The best way to solve the problem is to use the facility within XMLBeans to map target namespaces to Java packages. There is one more issue that is a little harder to work around. XMLBeans generates class files with the same name as the types and elements defined within the schema. So, reading the code can be a little challenging. The best suggestion here is to make your variable names meaningful and descriptive, which is a best practice anyway.

Date Created: November 2, 2020

GFIPM Organizational Role Mapping to GFIPM Technical Roles
*Organizational Role*	*Technical Roles*
Federation Manager Organization (FMO)	Certificate Authority (CA)
Identity Provider Organization (IDPO)	Identity Provider (IDP)
Service Provider Organization (SPO)	SAML Service Provider (SP) Web Service Consumer (WSC) Web Service Provider (WSP) Authorization Service (AS) Validation Service (VS)
Trusted Identity Broker Organization (TIBO)	Trusted Identity Broker (TIB)

GFIPM Service-Oriented Architecture Terminology Map
*GFIPM*	*SAML*	**WS-/WS-I***	*JRA*
Organizational Roles
Federation Manager Organization (FMO)	N/A	N/A	N/A
IDP Organization (IDPO)	N/A	N/A	N/A
SP Organization (SPO)	N/A	N/A	N/A
TIB Organization (TIBO)	N/A	N/A	N/A
Technical Roles
Certificate Authority (CA)	N/A	N/A	N/A
Identity Provider (IDP)	Same as GFIPM	WS-Federation: Security Token Service in the role of IDP or Security Token Service in the role of Attribute Service	Service Provider
SAML Service Provider (SP)	Service Provider	N/A	Service Provider
Web Service Consumer (WSC)	N/A	WS-Federation: Requestor	Service Consumer
Web Service Provider (WSP)	N/A	WS-Federation: Resource	Service Provider
Authorization Service (AS)	N/A	WS-Federation: Security Token Service in the role of Authorization Service	Service Provider
Validation Service (VS)	N/A	WS-Federation: Security Token Service in the role of Validation Service	Service Provider
Trusted Identity Broker (TIB)	N/A	N/A	Service Provider

NISS Knowledge Base

FAQs

Enter search criteria

Sort by

NISS Knowledge Base

FAQs

Use Search Filters

Enter search criteria

Sort by

What are GFIPM Technical Roles and Responsibilities?

How does GFIPM Organizational Role map to GFIPM Technical Roles

How does GFIPM relate to other prominent identity management paradigms in terms of terminology used to express various aspects of each paradigm?

Who are the points of contact for GFIPM?

What are the benefits of GFIPM?

What is GFIPM Cryptographic Trust Fabric?

What is GFIPM Overview?

How does the GRA relate to other Global or federal initiatives, such as NIEM, GFIPM, N-DEx, Global privacy, and fusion centers?

What is GRA?

What areas in implementation of information exchanges does GRA address?

What architectural compatibility issues are known to exist between the Global Reference Architecture and REpresentational State Transfer (REST) services?

What resources are available for GRA implementation?

How does GRA define a service interface?

How does Service Specifications support GRA?

Where do I download the Service Specification Package (SSP) templates for GRA?

What is N-DEx?

What are the core capabilities and functionality supported in N-DEx?

What kind of information is shared in N-DEx?

What are some of the features and services supported in N-DEx?

What is IEPD Clearinghouse?

Is there an Information Exchange Package Documentation (IEPD) for child support related filings?

What is an Information Exchange Package (IEP)?

What is the importance of Information Exchange Package Documentation (IEPD)?

What is an Information Exchange Package Documentation (IEPD)?

How can Informatiom Exchange Package Documantation (IEPD) be used to address specific business needs?

What is the difference between an Information Exchange Package (IEP) and an Information Exchange Package Documentation (IEPD)?

Two agencies identify some information they want to exchange. They find an existing IEPD that serves their purposes and want to use it. What are the steps after that to make it happen?

Can you point me to implementation experience and lessons learned from using reference IEPDs in the clearinghouse, especially the Incident Reporting IEPD?

What are some constraints techniques for widely reused objects in IEPD?

How many message sets should one IEPD cover:

How to deal with missing wantlist from an IEPD?

This document provides Information Exchange Package Documentation (IEPD) for the Memphis/UASI IncidentArrest data. This IEPD shall act as reference guide to ensure the Memphis/UASI Incident/Arrest data exchange conforms to the NIEM 2.1.

What is the AMBER Alert XML Schema?

How do I include PDF file binary data in the XML document?

What is XML?

What is an XML parser and why should I use one?

What are XMLBeans and when do I use them?

What is an XML Document?

What is Stylus Studio XML Editor?

Which USDO groups comprise the Global XML Structure Task Force?