Difference between revisions of "Software Statement"
(→CSP) |
(→CSP) |
||
(34 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
A json document that describes the provenance, certification and operational environment of an implementation of a software package on a computing machine. | A json document that describes the provenance, certification and operational environment of an implementation of a software package on a computing machine. | ||
+ | ===Goals=== | ||
+ | These goals are independent in the sense that the statement could address one or both of them. | ||
+ | # A statement about the level of assurance of the identity and testing criteria for the software package. | ||
+ | # A statement about the level of assurance of the authentication factors provided by the software package. | ||
+ | In all cases the statement must identify the software and the issuer making the statement. | ||
+ | |||
+ | ===Non-goals=== | ||
+ | # The statement is created by the process of programming and testing the software which does not address the assurance that can be assigned to the current state or processing of the software package. However, the software can make and sign such an additional statement on its own authority. Such an additional statement is not part of this document. | ||
+ | |||
==Context== | ==Context== | ||
# The context is a computing machine, like a [[Smart Phone]], in the possession of the user that allows the user to load [[Native App]]s. | # The context is a computing machine, like a [[Smart Phone]], in the possession of the user that allows the user to load [[Native App]]s. | ||
Line 6: | Line 15: | ||
# In determining an authentication assurance level (NIST 800-63-3B AAL2 or 3) a website needs to see some sort of attestation statement that can be used to determine the level of assurance that a user's credential will not be exposed. | # In determining an authentication assurance level (NIST 800-63-3B AAL2 or 3) a website needs to see some sort of attestation statement that can be used to determine the level of assurance that a user's credential will not be exposed. | ||
# All of the existing software statements have been focused on [[relying Party]] or clients in the OAuth jargon. | # All of the existing software statements have been focused on [[relying Party]] or clients in the OAuth jargon. | ||
+ | ===Goals=== | ||
+ | A json object signed by a private key of the CSP containing: | ||
+ | # An assertion about the operating environment both the operating system and the default settings for security features. | ||
+ | # An assertion about the specific native app name and version number as assigned by the o/s vendor. | ||
+ | # An assertion about the specific protections given to the user's private key (the user credential). | ||
+ | |||
===OAuth 2.0 Dynamic Client Registration Protocol=== | ===OAuth 2.0 Dynamic Client Registration Protocol=== | ||
*[https://tools.ietf.org/html/rfc7591#page-13 OAuth 2.0 Dynamic Client Registration Protocol] | *[https://tools.ietf.org/html/rfc7591#page-13 OAuth 2.0 Dynamic Client Registration Protocol] | ||
Line 157: | Line 172: | ||
* RFC 8258 ''OAuth 2.0 for Native Apps'' is a best practice document that requires all requests from native apps should only be made through external user-agents. This document assumes that those are browsers supplied by the o/s vendor or otherwise vetted as secure for the user. | * RFC 8258 ''OAuth 2.0 for Native Apps'' is a best practice document that requires all requests from native apps should only be made through external user-agents. This document assumes that those are browsers supplied by the o/s vendor or otherwise vetted as secure for the user. | ||
* [[Proof Key for Code Exchange]] is a method to secure interchange with native apps that has been implemented in client code running on the patient's [[Smart Phone]] by the CMS Blue Button API. | * [[Proof Key for Code Exchange]] is a method to secure interchange with native apps that has been implemented in client code running on the patient's [[Smart Phone]] by the CMS Blue Button API. | ||
− | * [SP 800-163 Rev. 1 Vetting the Security of Mobile Applications] | + | * [https://www.carinalliance.com/our-work/trust-framework-and-code-of-conduct/ CARIN code of conduct] with a [https://confluence.hl7.org/download/attachments/58656171/Carin%20Alliance%20WEDi.pdf slide deck] presented on 2019-07-31 at the WEDI summer forum. This version envisions that only voluntary compliance will be recommended. |
+ | * [https://csrc.nist.gov/publications/detail/sp/800-163/rev-1/final SP 800-163 Rev. 1 Vetting the Security of Mobile Applications]<blockquote>The level of risk related to vulnerabilities varies depending on several factors including the data accessible to an app. For example, apps that access data such as precise and continuous geolocation information, personal health metrics or personally identifiable information (PII) may be considered to be of higher risk than those that do not access sensitive data. In addition, apps that depend on wireless network technologies (e.g., Wi-Fi, cellular, Bluetooth) for data transmission may also be of high risk since these technologies also can be used as vectors for remote exploits. Even apps considered low risk, however, can have significant impact if exploited. For example, public safety apps that fail due to a vulnerability exploit could potentially result in the loss of life. To mitigate potential security risks associated with mobile apps, organizations should employ a software assurance process that ensures a level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its life cycle, and that the software functions in the intended manner [2]. In this document, we define a software assurance process for mobile applications. We refer to this process as an app vetting process.</blockquote> | ||
+ | * [https://developer.firstnet.com/firstnet/get-started/develop FirstNet app development and approval process]. More information is on their web site or the [[FirstNet]] wiki page.<blockquote>Just starting out? Select a platform. We recommend you select an [[Application Lifecycle]] Management Platform to track requirements, manage projects, release and support different versions of your app. They listed a recommended list of development platform and guidelines for each.</blockquote> | ||
===Capability Statement=== | ===Capability Statement=== | ||
Line 190: | Line 207: | ||
|- | |- | ||
|} | |} | ||
+ | |||
+ | Note that the capability statement is a mix of machine readable and human readable fields. | ||
==Problems or Threats== | ==Problems or Threats== | ||
− | # Spoofing the user by acquiring access to the user's authentication credentials. | + | # Spoofing the user by acquiring access to the user's authentication credentials that allow access to protected information. |
+ | # While high assurance authentication has been available for decades, user acceptance of [[Inconvenience]] of existing solutions has been very limited. | ||
==Solution== | ==Solution== | ||
+ | * Unlike most of the above solutions, this solution is directed explicitly, and exclusively, at code running on a user's mobile computing device, specifically on native apps running on Android and iOS operating systems. The statements apply to the entirety of the experience with includes directions on what features of the o/s must be enabled and which versions are acceptable to meet the needs of the trust framework that applies. | ||
* Each service will provide any user with a consent receipt. | * Each service will provide any user with a consent receipt. | ||
* In addition service will provide the following. | * In addition service will provide the following. | ||
===Trust Registry=== | ===Trust Registry=== | ||
− | entity statement | + | * Provides an entity statement for all of the participants in the trust ecosystem. |
+ | |||
===CSP=== | ===CSP=== | ||
− | software statement. | + | [[Credential Service Provider]] software statement. |
+ | |||
There are three audiences for software statements. They are represented in the following table by these codes: | There are three audiences for software statements. They are represented in the following table by these codes: | ||
# M = mandatory part of the software statement that the software can furnish to the [[Relying Party]]. | # M = mandatory part of the software statement that the software can furnish to the [[Relying Party]]. | ||
− | #H = Human readable required but may be part of consent receipt | + | # H = Human readable required but may be part of consent receipt (Note that this could be localized or accessible via the URL.) |
# R = recommended depending on local conditions | # R = recommended depending on local conditions | ||
+ | |||
+ | Some interesting context fields. The final document will be longer. It is expected that the machine readable version will be used for machine verification and the human readable fields will typically be accessible on the URL listed. The first three elements taken together are an unique identifier of the software running on the user's device at the the the statement was provided. The statement is signed by the CSP and is invariant over the lifetime of the software installation. | ||
+ | |||
+ | {|border="1" padding="2" width="799px" | ||
+ | | Element Name || Contents || Cat|| Explanation for category | ||
+ | |- | ||
+ | |name || identifier unique in publisher || M|| required to verify app - computer friendly - should require a version based on this | ||
+ | |- | ||
+ | |version|| monotonically increasing|| M ||Canonical business version required if updates to app are to preserve credential integrity. | ||
+ | |- | ||
+ | |platform || usually name of o/s ||M|| This or the optional source element provides context for the name which will be in a format determined by the platform (or source) | ||
+ | |- | ||
+ | |min-platform|| typically a version number || R || describes the minimal API support required by the platform | ||
+ | |- | ||
+ | |source || Location that hosts the app || || if absent, the platform will be considered as determining the source | ||
+ | |- | ||
+ | |experimental|| name || R ||A taxonomy of states will be provided | ||
+ | |- | ||
+ | |jurisdiction || || M |||Intended jurisdiction for maintenance and disputes, MUST not be a flag of convenience | ||
+ | |- | ||
+ | |user-authn ||json|| M || Method used to assure user agreement for valid authentication | ||
+ | |- | ||
+ | |date || Unix epoch|| M ||last modified - (perhaps we need date signed as a separate field?) | ||
+ | |- | ||
+ | |trust-registry|| uri || M || the location for an API to validate sites and apps | ||
+ | |- | ||
+ | |url || name || M ||Canonical identifier for this capability statement - all human readable elements will be found here | ||
+ | |- | ||
+ | |title|| ||| H || Human friendly, possibly localized | ||
+ | |- | ||
+ | |publisher || || H |||Who wrote the app, got it approved, or at least is responsible for maintenance and redress | ||
+ | |- | ||
+ | |contact || || H ||Contact details for the publisher | ||
+ | |- | ||
+ | |description|| || H |||Natural language description of the capability statement | ||
+ | |} | ||
+ | |||
+ | ===Proposal for Assurance=== | ||
+ | Following the pattern created by NIST SP 800-63-3 it is proposed to create levels of assurance for [[Smartphone]]s and software running on those phones with a [[Software Statement]]. | ||
+ | # Simplest level the app makes an assurance of its own identity, provenance and policies as well as the security configuration of the device it is running on. | ||
+ | # The assertion includes a description of the authentication requirements placed on the user and can accommodate, as installed on the smartphone, at least AAL2 level of assurance to to the relying party. The app will not run phones without support for key protection. | ||
+ | # The assertion is signed by an accredited testing body as meeting the highest level of assurance by a recognized accrediting body. | ||
==References== | ==References== |
Latest revision as of 09:45, 24 September 2024
Full Title or Meme
A json document that describes the provenance, certification and operational environment of an implementation of a software package on a computing machine.
Goals
These goals are independent in the sense that the statement could address one or both of them.
- A statement about the level of assurance of the identity and testing criteria for the software package.
- A statement about the level of assurance of the authentication factors provided by the software package.
In all cases the statement must identify the software and the issuer making the statement.
Non-goals
- The statement is created by the process of programming and testing the software which does not address the assurance that can be assigned to the current state or processing of the software package. However, the software can make and sign such an additional statement on its own authority. Such an additional statement is not part of this document.
Context
- The context is a computing machine, like a Smart Phone, in the possession of the user that allows the user to load Native Apps.
- The user will perform authentication with Web Sites on this device, some of which will require a high level of assurance of the user's authenticity.
- In determining an authentication assurance level (NIST 800-63-3B AAL2 or 3) a website needs to see some sort of attestation statement that can be used to determine the level of assurance that a user's credential will not be exposed.
- All of the existing software statements have been focused on relying Party or clients in the OAuth jargon.
Goals
A json object signed by a private key of the CSP containing:
- An assertion about the operating environment both the operating system and the default settings for security features.
- An assertion about the specific native app name and version number as assigned by the o/s vendor.
- An assertion about the specific protections given to the user's private key (the user credential).
OAuth 2.0 Dynamic Client Registration Protocol
A software statement is a JSON Web Token (JWT) RFC 7519 that asserts metadata values about the client software as a bundle. A set of claims that can be used in a software statement are defined in Section 2. When presented to the authorization server as part of a client registration request, the software statement MUST be digitally signed or MACed using JSON Web Signature (JWS) RFC 7515 and MUST contain an "iss" (issuer) claim denoting the party attesting to the claims in the software statement. It is RECOMMENDED that software statements be digitally signed using the "RS256" signature algorithm, although particular applications MAY specify the use of different algorithms.
For example, a software statement could contain the following claims: { "software_id": "4NRB1-0XZABZI9E6-5SM3R", "client_name": "Example Statement-based Client", "client_uri": "https://client.example.net/" }
- Health Relationship Trust Profile for OAuth 2.0 from the OpenID HEART working group also defines software statement for clients
Authorization servers MAY accept signed software statements as described in [RFC7591] issued to client software developers from a trusted registration entity. The software statement can be used to tie together many instances of the same client software that will be run, dynamically registered, and authorized separately at runtime. The software statement MUST include the following client metadata parameters:
- redirect_uris
array of redirect URIs used by the client; subject to the requirements listed in Section 2.2.3.1
- grant_types
grant type used by the client; must be "authorization_code” or "implicit”
- jwks_uri or jwks
c lient's public key in JWK Set format; if jwks_uri is used it MUST be reachable by the Authorization Server and point to the client's public key set
- client_name
human-readable name of the client
- client_uri
URL of a web page containing further information about the client
UK Open Banking Registration
- Dynamic Client Registration - v3.1. defines the APIs for a TPP to submit a Software Statement Assertion to an ASPSP for the purpose of creating OAuth clients that are registered with ASPSP. it includes a software statement JWS as a single element. The data model for the software statements issued by the Open Banking directory are documented as part of the Directory Specification.
Example SSA The elements defined in the software statement will consist of the following values.
Note that there are inconsistent applications of booleans or "Active" strings in the current data model.
Note that there are inconsistent applications of status flags case sensitivity.
The attributes required to be displayed by ASPSPs
{ "typ": "JWT", "alg": "ES256", "kid": "ABCD1234" } { "iss": "OpenBanking Ltd", "iat": 1492756331, "jti": "id12345685439487678", "software_environment": "production", "software_mode": "live", "software_id": "65d1f27c-4aea-4549-9c21-60e495a7a86f", "software_client_id": "OpenBanking TPP Client Unique ID", "software_client_name": "Amazon Prime Movies", "software_client_description": "Amazon Prime Movies is a moving streaming service", "software_version": "2.2", "software_client_uri": "https://prime.amazon.com", "software_redirect_uris": [ "https://prime.amazon.com/cb", "https://prime.amazon.co.uk/cb" ], "software_roles": [ "PISP", "AISP" ], "organisation_competent_authority_claims": [ { "authority_id": "FMA", // Austrian Financial Market Authority "registration_id": "111111", "status": "Active", "authorisations": [ { "member_state": "GBR", "roles": [ "PISP", "AISP" ] }, { "member_state": "ROI", "roles": [ "PISP" ] } ] } ], "software_logo_uri": "https://prime.amazon.com/logo.png", "org_status": "Active", "org_id": "Amazon TPPID", "org_name": "OpenBanking TPP Registered Name", "org_contacts": [ { "name": "contact name", "email": "contact@contact.com", "phone": "+447890130558" "type": "business" }, { "name": "contact name", "email": "contact@contact.com", "phone": "+447890130558", "type": "technical" } ], "org_jwks_endpoint": "https://jwks.openbanking.org.uk/org_id/org_id.jkws", "org_jwks_revoked_endpoint": "https://jwks.openbanking.org.uk/org_id/revoked/org_id.jkws", "software_jwks_endpoint": "https://jwks.openbanking.org.uk/org_id/software_id.jkws", "software_jwks_revoked_endpoint": "https://jwks.openbanking.org.uk/org_id/revoked/software_id.jkws", "software_policy_uri": "https://tpp.com/policy.html", "software_tos_uri": "https://tpp.com/tos.html", "software_on_behalf_of_org": "https://api.openbanking.org.uk/scim2/OBTrustedPaymentParty/1234567789", "ob_registry_tos": "https://registry.openbanking.org.uk/tos.html" } { Signature }
OpenID Connect Mobile Registration Profile
This spec is focused on Smart Phones
{ "iss": "https://registry.exampleregistry.com", "aud": ["https://accounts.operator1.com","https://accounts.operator2.com","https://accounts.operator3.com"], "exp": "1311281970", "iat": "1311280970", "jti": "id12345685439487678", "software_id": "4NRB1-0XZABZI9E6-5SM3R", "software_version": "2.2", "client_name": "Example Statement-based Client", "client_uri": "https://client.example.net/", "redirect_uris": ["https://client.example.org/callback", "https://client.example.org/callback2"], "token_endpoint_auth_method": "client_secret_basic", "grant_types": ["authorization_code"], "response_types": ["code"], "logo_uri": "https://client.example.org/logo.png", "scope": "openid", "contacts": ["ve7jtb@example.org", "mary@example.org"], "tos_uri": "https://client.example.org/tos.html", "policy_uri": "https://client.example.org/policy.html", "application_type": "web", "sector_identifier_uri": "https://other.example.net/file_of_redirect_uris.json", "subject_type": "pairwise", "id_token_signed_response_alg": "RS256", "allowed_claims": ["name", "family_name", "phone_number", "phone_number_verified"], "allowed_acrs": ["urn:modrna:acr:credential:loa2", "urn:modrna:acr:credential:loa3"], "registry_tos": "https://registry.exampleregistry.com/tos.html" }
- This json object MUST be signed as a JWS JOSE message which may then be included with other json objects in an encrypted JWE JOSE message.
- The issue of multiple signatures on a single JWS has not yet been addressed.
- [Editor's note:] Proposal to is to limit the signature algorithm to RSA to start with.
Security for Native Apps
- RFC 8258 OAuth 2.0 for Native Apps is a best practice document that requires all requests from native apps should only be made through external user-agents. This document assumes that those are browsers supplied by the o/s vendor or otherwise vetted as secure for the user.
- Proof Key for Code Exchange is a method to secure interchange with native apps that has been implemented in client code running on the patient's Smart Phone by the CMS Blue Button API.
- CARIN code of conduct with a slide deck presented on 2019-07-31 at the WEDI summer forum. This version envisions that only voluntary compliance will be recommended.
- SP 800-163 Rev. 1 Vetting the Security of Mobile Applications
The level of risk related to vulnerabilities varies depending on several factors including the data accessible to an app. For example, apps that access data such as precise and continuous geolocation information, personal health metrics or personally identifiable information (PII) may be considered to be of higher risk than those that do not access sensitive data. In addition, apps that depend on wireless network technologies (e.g., Wi-Fi, cellular, Bluetooth) for data transmission may also be of high risk since these technologies also can be used as vectors for remote exploits. Even apps considered low risk, however, can have significant impact if exploited. For example, public safety apps that fail due to a vulnerability exploit could potentially result in the loss of life. To mitigate potential security risks associated with mobile apps, organizations should employ a software assurance process that ensures a level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its life cycle, and that the software functions in the intended manner [2]. In this document, we define a software assurance process for mobile applications. We refer to this process as an app vetting process.
- FirstNet app development and approval process. More information is on their web site or the FirstNet wiki page.
Just starting out? Select a platform. We recommend you select an Application Lifecycle Management Platform to track requirements, manage projects, release and support different versions of your app. They listed a recommended list of development platform and guidelines for each.
Capability Statement
The HL7 FHIR Release 4 Resource CapabilityStatement describes actual server functionality or a desired server implementation. Capability Statements provide for a degree of automatic configuration and adaptation. However, capturing absolutely every variation that could impact the interoperability of two systems, let alone keeping that detailed information up-to-date as systems evolve through maintenance and upgrades, is rarely practical. Therefore, capability statements should be seen as an interim step. They provide a degree of automation. However, they also provide a great deal of human-readable content that can minimize the need for direct communication between the operators of the systems being configured to interoperate. The capability statement is only one part of the conformance module.
- TR = trust registry name
- M = Must
- R = Recommended
Some interesting context fields. The entire document is much much longer.
Element Name | Contents | Cat | Explanation for category |
name | identifier unique in TR | M | required for internal lookups computer friendly - should require a version based on this |
version | monotonically increasing | Canonical ibusiness version | |
url | name | Canonical identifier for this capability statement | |
title | Human friendly | ||
experimental } | name | R | boolean - should be multivariant |
contact | Contact details for the publisher | ||
date | last modified - perhaps we need date signed? | ||
publisher | Who wrote the app and got it approved | ||
description | Natural language description of the capability statement | ||
jurisdiction | Intended jurisdiction for capability statement |
Note that the capability statement is a mix of machine readable and human readable fields.
Problems or Threats
- Spoofing the user by acquiring access to the user's authentication credentials that allow access to protected information.
- While high assurance authentication has been available for decades, user acceptance of Inconvenience of existing solutions has been very limited.
Solution
- Unlike most of the above solutions, this solution is directed explicitly, and exclusively, at code running on a user's mobile computing device, specifically on native apps running on Android and iOS operating systems. The statements apply to the entirety of the experience with includes directions on what features of the o/s must be enabled and which versions are acceptable to meet the needs of the trust framework that applies.
- Each service will provide any user with a consent receipt.
- In addition service will provide the following.
Trust Registry
- Provides an entity statement for all of the participants in the trust ecosystem.
CSP
Credential Service Provider software statement.
There are three audiences for software statements. They are represented in the following table by these codes:
- M = mandatory part of the software statement that the software can furnish to the Relying Party.
- H = Human readable required but may be part of consent receipt (Note that this could be localized or accessible via the URL.)
- R = recommended depending on local conditions
Some interesting context fields. The final document will be longer. It is expected that the machine readable version will be used for machine verification and the human readable fields will typically be accessible on the URL listed. The first three elements taken together are an unique identifier of the software running on the user's device at the the the statement was provided. The statement is signed by the CSP and is invariant over the lifetime of the software installation.
Element Name | Contents | Cat | Explanation for category |
name | identifier unique in publisher | M | required to verify app - computer friendly - should require a version based on this |
version | monotonically increasing | M | Canonical business version required if updates to app are to preserve credential integrity. |
platform | usually name of o/s | M | This or the optional source element provides context for the name which will be in a format determined by the platform (or source) |
min-platform | typically a version number | R | describes the minimal API support required by the platform |
source | Location that hosts the app | if absent, the platform will be considered as determining the source | |
experimental | name | R | A taxonomy of states will be provided |
jurisdiction | M | Intended jurisdiction for maintenance and disputes, MUST not be a flag of convenience | |
user-authn | json | M | Method used to assure user agreement for valid authentication |
date | Unix epoch | M | last modified - (perhaps we need date signed as a separate field?) |
trust-registry | uri | M | the location for an API to validate sites and apps |
url | name | M | Canonical identifier for this capability statement - all human readable elements will be found here |
title | H | Human friendly, possibly localized | |
publisher | H | Who wrote the app, got it approved, or at least is responsible for maintenance and redress | |
contact | H | Contact details for the publisher | |
description | H | Natural language description of the capability statement |
Proposal for Assurance
Following the pattern created by NIST SP 800-63-3 it is proposed to create levels of assurance for Smartphones and software running on those phones with a Software Statement.
- Simplest level the app makes an assurance of its own identity, provenance and policies as well as the security configuration of the device it is running on.
- The assertion includes a description of the authentication requirements placed on the user and can accommodate, as installed on the smartphone, at least AAL2 level of assurance to to the relying party. The app will not run phones without support for key protection.
- The assertion is signed by an accredited testing body as meeting the highest level of assurance by a recognized accrediting body.