Merge pull request #123 from oauth-wg/n-a-txn-claim

moved txn field usage information to Security Considerations section

Author: tulshi

draft-ietf-oauth-transaction-tokens.md

@@ -348,7 +348,7 @@ JWT claims as well as defines new claims. These claims are described below:
 : REQUIRED Expiry time of the Txn-Token as defined in {{RFC7519}}
 
 `txn`:
-: REQUIRED A unique transaction identifier as defined in Section 2.2 of {{RFC8417}}. When used in the transaction token, it identifies the entire call chain. It is strongly RECOMMENDED to provide an identifier unique within the trust domain. If providing such an identifier is not possible, then a fixed value of "N_A" MAY be supplied.
+: REQUIRED A unique transaction identifier as defined in Section 2.2 of {{RFC8417}}.
 
 `sub`:
 : REQUIRED A unique identifier for the subject within the context of the `aud` trust domain. Unlike OpenID Connect, the `sub` claim is NOT associated with the `iss` claim.
@@ -623,6 +623,9 @@ Validation of a replacement Txn-Token, as well as any Txn-Token, is critical to
 ## Scope and Purpose processing
 The authorization model within a trust domain boundary is most often quite different from the authorization model (e.g. OAuth scopes) used with client external to the trust domain. This makes managing unintentional scope increase a critical aspect of the Transaction Token Service. The TTS MUST ensure that the requested purpose (`scope`) of the Txn-Token is equal or less than the scope(s) identified in the `subject_token`. This is also true of requesting a replacement Txn-Token. The TTS MUST ensure there is not unintentional increase in authorization scope.
 
+## Identifying Call Chains
+A Txn-token typically represents the call-chain of workloads necessary to complete a logical function initiated by an external or internal workload. The `txn` claim in the Txn-token provides a unique identifier that when logged by the TTS and each subsequent workload can provide both discovery and auditability of successful and failed transactions. It is therefore strongly RECOMMENDED to use an identifier, unique within the trust domain, for the `txn` value.
+
 # Privacy Considerations {#Privacy}
 
 ## Obfuscation of Personal Information