Hi Roman,
Thanks for your feedback, I just released a new version addressing your
comments!
-Daniel
Am 08.02.24 um 14:54 schrieb Roman Danyliw:
Hi!
I need to apologize here. I didn’t catch this email and was watching
for revised I-D indicator in the Datatracker. Thanks for producing
this revision over the winter break. The detailed explanations on the
WG deliberations on the specific guidance I asked about was very
helpful. Likewise, the new introductory text finds the right balance
in addressing how this document updates the others.
Practically, the revised draft in github addresses almost all of my
feedback. A few minor things from the previous thread:
*From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of * Daniel Fett
*Sent:* Thursday, December 28, 2023 8:35 AM
*To:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] AD Review of draft-ietf-oauth-security-topics-24
*Warning:*External Sender - do not click links or open attachments
unless you recognize the sender and know the content is safe.
Hi Roman,
thanks again for your feedback!
I have a few open questions below, but already incorporated most of
your (and Hannes) feedback in the editor's copy:
-
https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html
- Diff to published version:
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-oauth-security-topics&url_2=https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.txt
<https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-oauth-security-topics&url_2=https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.txt>
I plan to publish the next version once we have resolved the
discussion points below.
Also looking forward to feedback from the list and the co-editors!
-Daniel
Am 19.12.23 um 00:08 schrieb Roman Danyliw:
** Section 2.2.
The privileges associated with an access token SHOULD be restricted
to the minimum required for the particular application or use case.
Under what circumstances should access tokens not be restricted? Can this
be documented?
Due to the variety in architectures, I guess this would mostly boil
down to performance reasons and architectural limitations (resource
server or exact privileges are not known at the time of authorization).
I suggest that we add a sentence to discuss this to Section 4.10
<https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-24.html#section-4.10>.
[Roman] Please do. Thanks.
** Section 2.6.
It is RECOMMENDED to use end-to-end TLS between the client and the
resource server. If TLS traffic needs to be terminated at an
intermediary, refer to Section 4.13 for further security advice.
Is there further TLS guidance to provide? Could BCP 195 be used (RFC9325)?
I would be fine with adding "according to BCP 195" in the first
sentence. What do you think?
[Roman] That makes sense to me.
** Section 4.18.2. Formally cite that these are Javascript (?) examples.
I added that these are JavaScript examples. Do you think we need a
formal reference to ECMAScript? I don't think this would be very helpful.
[Roman] The compromise position would be to call it pseudocode and
make an editorial distinction that this is an example.
OLD
Clients MUST utilize exact string matching to
compare the initiator origin of an in-browser message with the
authorization server origin:
window.addEventListener("message", (e) => {
// validate exact AS origin
if (e.origin === https://honest.as.example) {
// process e.data.code and e.data.state
}
})
NEW
Clients MUST utilize exact string matching to compare the initiator
origin of an in-browser message with the authorization server origin.
For example, in Javascript-like pseudo code, this comparison could
look as follows:
window.addEventListener("message", (e) => {
// validate exact AS origin
if (e.origin === https://honest.as.example) {
// process e.data.code and e.data.state
}
})
Regards,
Roman
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
