Difference between revisions of "Software Statement"

From MgmtWiki
Jump to: navigation, search
(Context)
(OAuth 2.0 Dynamic Client Registration Protocol)
Line 7: Line 7:
 
===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]
  A software statement is a JSON Web Token (JWT) [RFC7519] that asserts
+
  A software statement is a JSON Web Token (JWT) [RFC7519] 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) [RFC7515] 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.
  metadata values about the client software as a bundle.  A set of
+
  For example, a software statement could contain the following claims:
  claims that can be used in a software statement are defined in
+
    {
  Section 2.  When presented to the authorization server as part of a
+
      "software_id": "4NRB1-0XZABZI9E6-5SM3R",
  client registration request, the software statement MUST be digitally
+
      "client_name": "Example Statement-based Client",
  signed or MACed using JSON Web Signature (JWS) [RFC7515] and MUST
+
      "client_uri": "https://client.example.net/"
  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.
 
  
 
==Problems or Threats==
 
==Problems or Threats==

Revision as of 20:29, 20 February 2020

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

 A software statement is a JSON Web Token (JWT) [RFC7519] 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) [RFC7515] 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/"
    }

Problems or Threats

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

References