Trust Federation Membership Validation

Introduction

This document lays out a method for doing get-requests for searching the IDEF Registry database. Searches can be done on services, companies, and service category. The method describes how people can determine the current membership of another digital entity in a Trust Framework, and find services in categories that matter to them.

These methods could be used together with a recommendation for adoption by the IDEF registry.

Context

Several Trust Frameworks exist to enable digital entities to establish the policies used by the digital entity are in conformance with established standards, regulations and commonly accepted policies.

Trust can be based on two sources, past behavior by the entity, or membership of the entity in a group whose membership has shown that they are trustworthy. The IDESG ecosystem seeks to provide trust by membership of digital entities in Trust Frameworks. This document describes how one digital entity can learn that some other digital entity is currently a member of a framework that they trust to provide and enforce policies that lead to trustworthy behavior. The value of the mark proving evidence of membership will only be valuable to the extent that all of the members show that they deserve the trust that the mark asserts. In this paper it is assumed that some other technology is used to create a trusted identifier of each digital entity.

A Trust Framework is defined by Kantara to be "a complete set of contracts, regulations or commitments that enable participating actors to rely on certain assertions by other actors to fulfill their information security requirements." In this document the objective is simply to allow two digital entities (actors) to satisfy each other as to the membership of the other in a mutually acceptable trust framework. The only user experience element discussed is a multiresolution mark or logo with URL that will enable the user to learn about proof of the authority of the digital entity to display the mark that correspond to the trust framework.

An Identity Ecosystem is defined to be an online community of users and digital entities that are bound by a common set of technologies, processes and policies, that is, by one or more Trust Frameworks.

As general rule, the membership validation is strictly between digital entities and the user is unaware of the activity which is typically hidden from the user. Some inevitable confusion arises when a unique digital identifier is conflated with a user understandable name for a digital entity. In particular there is no standard way for the RP to acquire display name of the IdP using dynamic registration. The only methods available today require static (manual) registration of the RP with the IdP. Since the user will always be the ultimate source of trust for activities in the digital realm, it is necessary that digital identities are not created with the specific intent to confuse trust decisions. It is understood that this is not an easy requirement to satisfy.

It should be pointed out that the concept of a framework membership requirement creates a closed system. That is good for security, but somewhat at odds with interoperability. On the other hand it does make it easier for OpenID to be deployed in corporations or consortia.

The Problem

No widely accepted standard method exists for distinct digital entities in a trust framework to prove their conformance with the policy standards of the trust framework to each other.

No widely accepted standard method exists for securely identifying digital entities or trust frameworks with a name that a user can use for a trust deciscion. The best that exists today is TLS Extended Validation Certificates which do tend to have a short host name. The user involvement in trust decisions does need to be described in any specification of trust frameworks. In some cases it is the guardian of the user that needs to be involved in the trust decision.

The Solution

Several potential solutions were considered.

1. Public Key Infrastructure (PKI) depends on the existence of a chain of trust back to a root Trust Anchor. It would be possible for a Trust Framework to establish their own Trust Anchor and issue certificates. Creating a Certificate Authority for Trust Framework Membership is expensive but effective and well known. One deployed example of this method is the UK Open Banking effort.
2. Online Certificate Status Protocol can be used to test the validity of a certificate without relying on the CRL of PKI. It could be the basis for trust framework membership validation. Using existing service provider certificates and providing some sort of online check of that cert with the Framework membership service would be less expensive.
3. Account Authority Digital Signature (AADS) uses the public key technology without PKI. Avoiding the expense of deploying X.509 certificates of PKI would result in the lowest cost from Framework Membership Validation. Note that this method does not mean that PKI certificates are not acquired by members of the federation, only that the federation does not deploy its own PKI infrastructure. The following proposed solution for the IDEF is based on AADS.

These are some of the ways to establish trust, they all require the existence of a Trust Anchor at a well-know address of the Trust Framework. Note that TLS (HTTPS) is required before trust of digital entities can be considered.

1. Use the URL of the digital entity to identify it. While the URL was not designed to be user friendly, many security schemes depend on the user understanding the importance of the URL as a unique identifier for a digital entity. Note the confusion created by conflating a user understandable name with a unique digital identifier. This method requires one of the following to be used as the digital entity's unique identifier:
   1. The host name. This is simple, generally human readable and contains no weird punctuation. Many browser users understand the meaning of this name, but there are attacks using non-ASCII characters that confuse users with names similar to ones that the users do trust. Note the confusion created by conflating a user understandable name with a unique digital identifier.
   2. The host name plus the port number. This is the method selected by the TLS standard. This appears to users of commercial sites as the same as the above choice since commercial sites use the default port number 443.
   3. The host name plus the port number plus the path. This is the method selected by the OpenID standards. It is very easy to confuse users with this choice.
2. Use the public key of the SSL cert for the identity of the digital entity.
3. The service provider creates a name, potentially localized, by which it would like to be known.

If the service wants to use an email address as an identifier for the digital entity to enable the user to contact the manufacturer, that should be permitted.

Create a web site for the Trust Anchor that can be queried using some part of the identifier. This site should allow search terms and return all of the identifiers that match the query. This step is required for proving membership in a Trust Framework, but is optional for digital entities that just wish to self-assert their identifier and policies. In an ideal world the policies should be machine readable as well as user understandable.

Proposed formats for keys and identifiers

The Trust Anchor end point MUST respond to queries with a list of all members matching the query with a key and at least one identity. The format of the identity can be specified within the range listed below. The Trust Anchor or any service Provider would provide configuration information with a well-known URI (registered with the IETF) such as:

 https://idesg.org/.wellknown/idesg-configuration

The Trust Anchor MUST have a logo and associated URL describing the category of each member and the terms and conditions that are met to permit the display of the logo. The Trust Anchor SHOULD provide the logo in different resolutions as might be needed by member web sites.

The Trust Anchor MUST provide all data attributes (claims) that are defined as mandatory by the Trust Framework. For example many trust frameworks will have levels of assurance or access that are assigned to members based on their role.

The service provider MUST provide public keys in JWK Set format, such as the following 2048-bit RSA key:

{
 "keys": [
   {
     "alg": "RS256",
     "e": "AQAB",
     "n": "o80vbR0ZfMhjZ...",
     "kty": "RSA",
     "kid": "rsa1"
   }
 ]
}

The service provider MAY provide public keys in X.509 format if the certificate template includes the identifier (DN) of the service provider and of the framework(s) that have certified it.

The service Provider MUST associate their public keys with an identity that is either:

The URI without the scheme (which could be either https:// or mailto://)

The X.509 CN provided that is user-friendly.

A localized name of its own choosing.

The service Provider MAY provide other identities, attributes and service documentation, such as URL pointers to policies and service terms of use.

POET Payload

 {
  "scope": "openid profile patient/*.read",
  "software_id": "4NRB1-0XZABZI9E6-5SM3R",
  "redirect_uris": [
    "https://apps-dstu2.smarthealthit.org/cardiac-risk/"
  ],
  "exp": 1563564064,
  "client_uri": "https://apps-dstu2.smarthealthit.org/cardiac-risk/",
  "initiate_login_uri": "https://apps-dstu2.smarthealthit.org/cardiac-risk/launch.html",
  "iat": 1500492064,
  "iss": "endorsements.transparenthealth.org",
  "client_name": "Cardiac Risk App",
  "grant_types": [
      "authorization_code"
  ],
  "token_endpoint_auth_method": "client_secret_basic",
  "logo_uri": "https://gallery.smarthealthit.org/img/apps/66.png"
 }

Proposed Request Message

All of the data provided by the registry is public and so any internet device can send a request query string which includes the response_type parameter which indicates HTML or JSON for human or machine readable format. If there is no query string the first 25 entries are returned.

These are the parameters that can be included in the query sting:

• response_type OPTIONAL currently defined values are HTML (the default) or JSON
• framework_category OPTIONAL selects the types of site sought.
• service_match OPTIONAL If strictly alphanumeric this is treated as "contains". If any other characters are present it is treated as a "regex" on the name of the member. If absent all members are returned.
• company_match OPTIONAL If strictly alphanumeric this is treated as "contains". If any other characters are present it is treated as a "regex" on the name of the member. If absent all members are returned.
• quantity OPTIONAL numeric. If absent only the first 25 entries are returned.

https://idefregistry.org/query?{querystring]

Federation Office

idefregistry of metadata statement from the IDESG about itself at address "https://idesg.org/fed"

IDESG is operating as Federation Operator (FO) according to the OpenID Connect Federation 1.0. It is the Trust Anchor for the signature of any signed JWT relating to the framework.

 {
  "framework_category": "idesg fo",
  "contacts": ["rp_helpdesk@idefregistry.org"],
  "redirect_uris": ["https://idefregistry.org/rp1"],
  "signing_keys_uri": "https://idefregistry.org/jwks",
  "logo_uri": "https://idefregistry.org/logo.jpg",
  "policy_uri": "https://idefregistry.org/policy.html",
  "tos_uri": "https://idefregistry.org/tos.html"
 }

idefregistry of metadata statement about a registrant "http://idesg-rp.azurewebsites.net/"

 {
   "framework_category": "idesg relying_party",
 }

but now we want to publish a list of compliant parties according the search criteria show what a url would be and the html vs. json output in response.

this needs to be compared to UK open banking security guidence as well

Appendix - definitions

signing_keys

OPTIONAL. (I think we can leave this out) A JSON Web Key Set (JWKS) representing the public part of the entity's signing keys.

The keys that can be found here or at signing_keys_uri must not be confused with the keys that an OIDC entity is using for Authorization/AccessToken/RefreshToken/UserInfo requests and responses. Those keys are found at jwks_uri or in the case of client registration also possibly as values to jwks. The signing keys are used to sign metadata statements and can also be used by an OP to sign a client registration request response.

signing_keys_uri

OPTIONAL. (perhaps required - see signed jwks below) Location where a JWKS representing the public part of the entity's signing keys can be found. SHOULD return the Content-Type "application/jose" to indicate that the JWKS is in the form of a JSON Web Signature (JWS) using the JWS Compact Serialization. The signing key used to sign the JWKS belongs to the immediate superior. That is, the entity that signs this entity's metadata statement also signs the JWKS stored at signing_keys_uri.

metadata_statements

OPTIONAL. JSON object where the names are federation identifiers and the values a signed JSON documents containing compounded metadata statements rooted in that federation. There is one value per name.

metadata_statement_uris

OPTIONAL. JSON object where the names are the federation identifiers and the values are URLs pointing to a compounded metadata statement (CMS) rooted in that federation. Each URL points to just one CMS.

service_documentation

OPTIONAL. URL of a page containing human-readable information that developers might want or need to know when using a server.

signed_jwks_uri

OPTIONAL. (I suggest making this required) This is the signed version of the jwks_uri parameter defined in OpenID Connect Dynamic Client Registration 1.0. SHOULD return the Content-Type "application/jose" to indicate that the JWKS is in the form of a JWS using the JWS Compact Serialization. The key used to sign the JWKS can be found in signing_keys or signing_keys_uri.

framework_category

OPTIONAL. Metadata statements that are used in different roles will contain different requirements. For example, information that an IdP publishes about itself is not the same as what an RP wants to use. This together with the differences in the roles between an IdP and an RP, means that policies for RPs will not be the same as for IdPs. This parameter can be used to limit the usage to a specific role or roles. The framework_category value is a case sensitive string. Absence of the field implies that all data or certification on all categories is required. In the IDESG federation only the roles for which certification is granted are defined. One site can be certified for more than one role. The corresponding roles are:

 
1 relying_party
 certified as a Relying Party that is able to get external authentications known or as a client in OpenID terms (if they use internal authentication they must get certified as authentication as well.

2 authentication_provider
 certified as a Identifier Provider, Registration Authority or as the source of and identifier used in authentication (like mailto:) as well as the source of the subject Identifier (sub).

3 authorization provider
  certified to authorize access to user private information (or other resources) must include agreement to acquire resource owner consent to authorize release of information

4 attribute_provider
 certified as an Attribute Provider, or in OpenID terms as a user_info endpoint. Also any site that provides access to resources that are protected by privacy, health, age-restrictions or other regulations.

5 intermediary_provider
  certified as a provider of multiple functions, or as one that is not otherwise covered, for example a Privacy Enhancing Technology Provider, Trusted Third Party or a federation server.

Note that the term Identity and Attribute Provider (or OpenID Provider) can be applied to any set of the categories 2-5.

References and Coordination with other groups

• OpenID Connect Federation 1.0 and the references in that document define most of the terms used in the Federation Office section above.
• The JSON Web Token (JWT) IETF RFC 7519 is to be used as the format for the metadata messages described above.
• The JSON Web Key (JWK) IETF RFC 7515 is to be used for the key set.
• Basic interactions in a single Trust Framework was an early start at building a standard set of interactions between digital entities involved in a Trust Framework.
• Federation for Identity and Cross-Credentialing Systems (FiXs) works for standardization within the U. S. Federal government. It has no specific protocols of its own.
• Transglobal Secure Collaboration Program was originally formed to use U. S. DoD PIV smart cards to establish trusted connections among the DoD Contractors. It has since developed a NIST pilot program to show how that trusted connection can be expanded beyond their narrow scope for use with financial institutions.
• The Trust Frameworks Catalog lists InCommon, Kantara and potentially other trust frameworks recognized by the IDESG.
• The Core OpenID Connect spec contains information on localization of names.
• The OpenID Connect Discovery Document contains other information that could be reported by the Trust Anchor to help understand the scope of their work.

  "service_documentation":
    "http://server.example.com/connect/service_documentation.html",
  "ui_locales_supported":
    ["en-US", "en-GB", "en-CA", "fr-FR", "fr-CA"]

• There is a draft federation document of the AB/Connect group of the OpenID that has useful components, but some unacceptable requirements.
• The mobile software registration profile from OpenID does show the way to provide information about the client (RP) software, but even it has not defined a friendly name that a user could understand.
• Pre Oauth Entity Trust a means to represent third-party application endorsement for health care applications. POET’s goal is to help consumers distinguish between applications that have an endorsement versus applications that have no pedigree (i.e untrusted and could be malicious).