IDESG RP application description page.

The purpose of this site is to provide an IDESG compliant example of a working relying party web site that can be used by anyone desiring to create their own compliant web site.


The protocol implemented in this example is OpenID connect, which is the most commonly used protocol by the largest Identity Providers at the time this example was written . It is possible to extend this code to use any protocol.

OpenID Connect Impelmenters Guideline »

The OpenID Connect standard is more of a guideline that is independantly implemented by many IdPs with different terminology, requirments and even permissible character sets. The ASP.NET framework comes with some modules implemented for Twitter, Google, FaceBook and Microsoft. Other IdPs are likely to require special code as each of them become available. The good news for a open standard like this one is that other implementers are likely to have already addressed those new IdPs in modules available for free on the web.

The Basic Functional Requirement of the IDEF registry requires that open standard protocols be used for interoperability. Standard Data Exchange »

User Agents

Web sites like this example are designed to work with a variety of browsers of all sizes and orientations. This is achieved in the example by dividing the content into panels that can be rearranged by the browser in horizontal or vertical stacking depending on the size and orientation of the device displaying the content. Since the web is constantly changing and the information that was displayed to the user cannot easily be recovered should there be any dispute about what the user actually agreed to, the common browser will need to be replaced with a more trustworthy user agent before it will be possible for the relying party to make any sort of claim about what information the user intended to release to the RP and for what purposes. Stay tuned for more on that to come in the future.

Need a good link here »

Data Retention

Two basic functional requirments apply to data retention. In part this is because of two data collections that are often created with little understanding of the impact each has on security and on privacy. The SQL data base contains user's personal information that should be collected with the users' intent clearly recognized and honored. The log files contain user's personal information as well, but that collection does not consider the user's intent. Also not that thee will be business an legal reqirement that require data retention where payment or court ordered disclouse mandates that data be available to support future evaluation of past actions. It is even required by privacy regulation that data proving compliance is retained. Still it is important the the privacy of the information is resptected. With those ideas in mind let's look at the two requirents.

Privacy concerns mandate that no data be retained that is not needed for purposes that the user intends. Data Minimization »

Security concerns mandate that no data is deleted that might help understand whether past activity was unlawful or harmful. Security Logs »

Federated Identity

Since this example will accept authentication tokens from Google and FaceBook as well as from an internal data store, it could be considered to support "Federated Identity Management". A word of warning is in order since many uses of the term Federated Identity come with requirements on the Identity Provider (IdP) that go beyond the traditional meaning of identity. For example there may be attributes about the method used to "proof" the real world person that is referenced by the identifier, or that the identifier is only used for individuals that are employees of the organization running the IdP. Either of these could be supported by this example if the developer limits the IdP included to those that require the desired attributes. The NIST has published a draft Internal Report (8149) that defines "Trust Frameworks" that could support any degree of trust that the developer might be required to include in a real world implementation of an RP. Just note that using Google, or similar IdPs, will not support that level of attribute verification. Properly speaking attribute verification is the provenance of Authorization, which is only avilable here by use of the tag [Authorize] in a controller to give access to a particular web page. It is possible to modify that tag to include the spefic user roles that are authorized.

Learn More »

Federating with Google

Before trying to add Google as an Identity Provider (IdP) it is necessary to register your web site with them. One item that seems to be required for the ASP.NET code is to select Google+ API. Otherwise you will get an error when the Google button is clicked on the website login page.

Google registration »

Privacy concerns mandate that no more data is requested from Google than is required for this applicaton. It is incumbent on the RP code to verify the request packet sent for data that is actually required. Data Minimization »

Federating with FaceBook

Before trying to add FaceBook as an Identity Provider (IdP) it is necessary to register your web site with them. When running tests with developers, the site can continue to be marked private, which is the default. As soon as you want to start beta testing with non-admin users the site need to be marked as public. This is a simple yes/no selector on the review-status page.

FaceBook registration »

Privacy concerns mandate that no more data is requested from FaceBook than is required for the applicaton. It is incumbent on the RP code to verify the request packet sent for data that is actually required. Data Minimization »