Software Statement

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.

Context

1. The context is a computing machine, like a Smart Phone, in the possession of the user that allows the user to load Native Apps.
2. 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.
3. 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.

OAuth 2.0 Dynamic Client Registration Protocol

• 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 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

OpenID Connect Mobile Registration Profile

• OpenID Connect Mobile Registration Profile 1.0

{

      "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"

} [Editor's note:] Cross-check with HEART and Blue Button Plus. Multiple Software Statement per Software ID.

[Editor's note:] Proposal to is to limit the signature algorithm to RSA to start with.

[Editor's note:] What claims are required to carry information about MNO T&Cs or more general authz data?.

Problems or Threats

1. Spoofing the user by acquiring access to the user's authentication credentials.