Make access token mandatory for continuation API calls. #129
Conversation
jricher
added
the
Pending Merge
|
This seems to follow the consensus of the working group as discussed at the meeting and on the list, changes will be merged unless there is a clear alternative proposal accepted by the working group. |
| new `continue` response MUST include a bound access token as well, and | ||
| this token SHOULD be a new access token. | ||
| The new `continue` response MUST include a bound access token as well, and | ||
| this token SHOULD be a new access token, invalidating the previous access token. |
There was a problem hiding this comment.
Why SHOULD? Are there cases where there's a good reason to retain an old one? I am sure this detail is critical for any formal security proof.
There was a problem hiding this comment.
I fully agree this is a MUST. Dick had another view however.
There was a problem hiding this comment.
If we need to call WG consensus on this, fine. We cannot have SHOULDs just because we are unable to reach agreement. Quoting RFC 2119, "This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." Which implies that we need to say when it may be appropriate to keep the old one.
There was a problem hiding this comment.
The best would be for Dick to reexplain his use case (and other people as well if it makes sense) and then we can decide as a group. Otherwise by default, I believe a MUST applies here.
There was a problem hiding this comment.
This PR doesn't change the behavior here, so we'll track whether this should be a SHOULD/MUST in a separate issue: #147
More text to be added into security considerations later when that's more filled out
|
How was @yaronf's comment about choosing just one method to keep it simple? Why do we need an access token and a URL? |
|
@dickhardt not sure i understand your question |
|
The AS is choosing how to identify a request by a unique URL, an access token, or having only request at a time from a client. Lots of implementation choices and opportunities to make mistakes -- and overly complex. |
|
There seemed to be some agreement during the IETF109 call that we indeed had to chose between the 2 alternatives. Now that leaves the question of which alternative to select. Between the 2, the editors have proposed (with explanations) to make access tokens mandatory. |
Co-authored-by: Warren Parad <wparad@users.noreply.github.com>
jricher
removed
the
Pending Merge
Closes #67