Stop.
Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: OAuth <oauth-boun...@ietf.org> on behalf of oauth-requ...@ietf.org
<oauth-requ...@ietf.org>
Sent: Thursday, February 8, 2024 8:54:25 AM
To: oauth@ietf.org <oauth@ietf.org>
Subject: OAuth Digest, Vol 184, Issue 15
Send OAuth mailing list submissions to
oauth@ietf.org
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
oauth-requ...@ietf.org
You can reach the person managing the list at
oauth-ow...@ietf.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."
Today's Topics:
1. Re: AD Review of draft-ietf-oauth-security-topics-24
(Roman Danyliw)
----------------------------------------------------------------------
Message: 1
Date: Thu, 8 Feb 2024 13:54:17 +0000
From: Roman Danyliw <r...@cert.org>
To: "m...@danielfett.de" <m...@danielfett.de>, "oauth@ietf.org"
<oauth@ietf.org>
Subject: Re: [OAUTH-WG] AD Review of
draft-ietf-oauth-security-topics-24
Message-ID:
<bn2p110mb1107c23d504a0aeb3cf963bbdc...@bn2p110mb1107.namp110.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://mailarchive.ietf.org/arch/browse/oauth/attachments/20240208/90c2eed1/attachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------------------------------
End of OAuth Digest, Vol 184, Issue 15
**************************************
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
