Allow for alternatives to RFC8693 #254
Conversation
There was a problem hiding this comment.
If we want to leave the door open for people to define their own mechanisms for obtaining a transaction token, then I think we should just say up front...
This specification defines a method to obtain a transaction token remotely over HTTP. Other methods used to obtain a transaction token conforming to this specification are out of scope and may be defined by other specifications.
Then we can say... if the transaction token request is made according to this specification it MUST ...
Co-authored-by: Brian Campbell <[email protected]>
Co-authored-by: Brian Campbell <[email protected]>
Co-authored-by: Brian Campbell <[email protected]>
|
|
||
| ### Initial Creation | ||
| Txn-Tokens are typically created when a workload is invoked using an endpoint that is externally visible, and is authorized using a separate mechanism, such as an OAuth {{RFC6749}} access token. This workload then performs an OAuth 2.0 Token Exchange {{RFC8693}} to obtain a Txn-Token. To do this, it invokes a special Token Service (the Txn-Token Service) and provides context that is sufficient for it to generate a Txn-Token. The context information provided to the Txn-Token Service MAY include: | ||
| Txn-Tokens are typically created when a workload is invoked using an endpoint that is externally visible, and is authorized using a separate mechanism, such as an OAuth {{RFC6749}} access token. The externally visible endpoint exchanges the external authorization token for a transaction token before sending it to the workload. The transaction token may be obtained through a local interface, or it may be requested from a remote server. |
There was a problem hiding this comment.
We need to update this language to take care of the case where there is no external authorization token. The part of the sentence "...exchanges the authorization token for a transaction token" reads like you assume there will always be an external authorization token
There was a problem hiding this comment.
@tulshi I think if you have no token, you send a selff-signed token, or even an unsigned token. Perhaps we just change the "authorisation token" to "token"?
There was a problem hiding this comment.
This whole paragraph is couched with "typically" to start with, "Txn-Tokens are typically created ... " so I don't think the case where there is no external authorization token is being precluded.
There was a problem hiding this comment.
@tulshi - Following on from our conversation, I had a second read of this section.
- I thinkBrian's point is valid - the paragraph is descriptive of a typical case, nnot normative or constraining.
- As written, it describes the initial transaction token creation, so does not preclude the creation of a replacement transaction token (or other uses for creating an initial token).
See #189