Introduced/used the phrase processed SD-JWT payload in Section 8.1 on Verifying the SD-JWT (#456)

* Introduced the phrase processed SD-JWT payload in the end of the (#sd_jwt_verification) on Verifying the SD-JWT

* typo fix

* henceforth will henceforth be herein

* words

Author: bc-pi

draft-ietf-oauth-selective-disclosure-jwt.md

@@ -866,7 +866,7 @@ an SD-JWT:
 5. If any Disclosure was not referenced by digest value in the Issuer-signed JWT (directly or recursively via other Disclosures), the SD-JWT MUST be rejected.
 6. Check that the SD-JWT is valid using claims such as `nbf`, `iat`, and `exp` in the processed payload. If a required validity-controlling claim is missing (see (#sd-validity-claims)), the SD-JWT MUST be rejected.
 
-If any step fails, the SD-JWT is not valid and processing MUST be aborted.
+If any step fails, the SD-JWT is not valid, and processing MUST be aborted. Otherwise, the JSON document resulting from the preceding processing and verification steps, herein referred to as the processed SD-JWT payload, can be made available to the application to be used for its intended purpose.
 
 It is up to the Holder how to maintain the mapping between the Disclosures and the plaintext claim values to be able to display them to the End-User when needed.
 
@@ -1935,6 +1935,7 @@ data. The original JSON data is then used by the application. See
 
    * Clarify, add context, or otherwise improve the examples
    * Editorial and reference fixes
+   * Better introduce the phrase processed SD-JWT payload in the end of (#sd_jwt_verification) on Verifying the SD-JWT
    * Moved considerations around unlinkability to the top of the Privacy Considerations section
 
    -11