Clarify authentication requriements #239
Conversation
Attempt at simplifying both client and server authentication requirements throughout the draft.
Co-authored-by: Yaron Sheffer <[email protected]>
| WIMSE: | ||
| title: WIMSE Workload to Workload Authentication | ||
| target: https://www.ietf.org/archive/id/draft-ietf-wimse-s2s-protocol-06.html | ||
| author: | ||
| - name: Brian Campbell | ||
| org: Ping Identity | ||
| - name: Joe Salowey | ||
| org: CyberArk | ||
| - name: Arndt Schwenkschuster | ||
| org: SPIRL | ||
| - name: Yaron Sheffer | ||
| org: Intuit |
There was a problem hiding this comment.
is there reason to not use the I-D.ietf-wimse-s2s-protocol style notation that (hopefully) pulls in a lot of this automatically?
also using the name of the WG for one doc from that WG doesn't seem quite right
| WIMSE: | |
| title: WIMSE Workload to Workload Authentication | |
| target: https://www.ietf.org/archive/id/draft-ietf-wimse-s2s-protocol-06.html | |
| author: | |
| - name: Brian Campbell | |
| org: Ping Identity | |
| - name: Joe Salowey | |
| org: CyberArk | |
| - name: Arndt Schwenkschuster | |
| org: SPIRL | |
| - name: Yaron Sheffer | |
| org: Intuit |
There was a problem hiding this comment.
If there are better ways to create references, let's use that (I am not a tooling expert).
And yes - agreed on overreach in using the WIMSE tag...
There was a problem hiding this comment.
thanks @PieterKas, I think this is moving in the right direction. I've got some suggestions - mostly tooling syntax stuff and a few (hopefully) minor things.
Co-authored-by: Brian Campbell <[email protected]>
Co-authored-by: Brian Campbell <[email protected]>
Co-authored-by: Brian Campbell <[email protected]>
Co-authored-by: Brian Campbell <[email protected]>
|
Thanks @bc-pi - I appreciate the review - changes accepted. |
| ## Client Authentication | ||
| If using the `actor_token` and `actor_token_type` parameters of the OAuth 2.0 Token Exchange specification, both parameters MUST be present in the request. The `actor_token` MUST authenticate the identity of the requesting workload. | ||
| ## Use of 'actor_token' | ||
| If using the `actor_token` and `actor_token_type` parameters of the OAuth 2.0 Token Exchange specification {{RFC8693}}, both parameters MUST be present in the request. The `actor_token` can authenticate the identity of the requesting workload. |
There was a problem hiding this comment.
I want to resolve this as the last open comment before merging. For my own eduication, I am curious about the choice of "can" here vs a normative MUST or MAY.
There was a problem hiding this comment.
I also am curious. If the actor_token does not identify the identity of the requesting workload then it seems that its use is not for the purpose of client authentication which was the original reason for including the text at all.
Co-authored-by: Brian Campbell <[email protected]>
Co-authored-by: Brian Campbell <[email protected]>
Attempt at simplifying both client and server authentication requirements throughout the draft (see #198, #198 and #218)