Re: [OAUTH-WG] Warren Kumari's No Objection on draft-ietf-oauth-dpop-14: (with COMMENT)

[Daniel Fett]

Hi Warren,

we addressed your comments in -15 which we just uploaded: 
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-15.html


-Daniel


Am 12.04.23 um 01:18 schrieb Warren Kumari:





On Tue, Apr 11, 2023 at 4:10 PM, Brian Campbell 
 wrote:


Thank you, Warren, for the review and ballot. I've replied inline
below and put together this small PR with corresponding edits:
https://github.com/danielfett/draft-dpop/pull/183/files


On Tue, Apr 11, 2023 at 1:10 PM Warren Kumari via Datatracker
mailto:nore...@ietf.org>> wrote:

Warren Kumari has entered the following ballot position for
draft-ietf-oauth-dpop-14: No Objection

When responding, please keep the subject line intact and reply
to all
email addresses included in the To and CC lines. (Feel free to
cut this
introductory paragraph, however.)


Please refer to

https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/



for more information about how to handle DISCUSS and COMMENT
positions.


The document, along with other ballot positions, can be found
here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/




--
COMMENT:
--

Thank you for writing this; I found it a fascinating and
informative read.


Appreciate that! Thanks :)


I don't have any particularly substantive comments, but I do
have some nits and
similar to hopefully further improve the document.

1: "These stolen artifacts can later be used together
independent of the client
application to access protected resources." -- I found this
really hard to
parse. I think that some of it is the "used together
independent" formulation -
adding a comma would help, but I think just dropping
"together" works even
better (it does say "artifacts" in plural, so that's already
covered?)


Indeed that is really hard to parse. I agree with dropping the
word "together".



Ta!




2: "Properly audience restricting access tokens can prevent
such misuse" - I
think that it would be helpful to reword this, or find a
reference for
"audience restricting"


That sentence caught the ire of Éric Vyncke in his review/ballot
and already had one attempt at improvement by me

.
But I can also add a reference, of sorts. I'm not aware of a
good/easy reference for the concept of audience restricting but
can point to the RFC7519 JWT `aud` claim as an example of .



Okey dokey, thanks.




3: Might it be worth adding a reference for XSS? I'm guessing
that the audience
will already be familiar, but if not,
https://owasp.org/www-community/attacks/xss/
 ?


I feel like "cross-site scripting (XSS)" stands on its own okay
and still gives an unfamiliar audience enough to search for more
info.


Fair 'nuff.



4: Question: Why is the Nonce optional? Perhaps I missed it,
but I was unable
to find any discussion (I was expecting something in Sec 8,9
or 10) providing
some reason why a server might not use a nonce (the closest I
found was "The
logic through which the server
   makes that determination is out of scope of this
document.", so I'm guessing
   that there *is* a reason, but... )


Long story short, the reason is basically that there's complexity
and extra round trip costs in using it. And there were and are
differing perceptions of its value in different circumstances. The
rough consensus was to leave its use (if/when/how) at the
discretion of the server.



Okey dokey, works for me. Feel free to ignore this comment, but 
mentioning that some implementations might choose not to use a nonce 
because of "complexity and extra round trip costs" might be helpful 
for others like me who were mystified.

(I really do mean feel free to ignore this, I won't be offended :-P)
W




/CONFIDENTIALITY NOTICE: This email may contain confidential and
privileged material for the sole use of the intended recipient(s).
Any review, use, distribution or disclosure by others is strictly
prohibited.  If you have received this communication in error,

Re: [OAUTH-WG] Warren Kumari's No Objection on draft-ietf-oauth-dpop-14: (with COMMENT)

[Warren Kumari]

On Tue, Apr 11, 2023 at 4:10 PM, Brian Campbell 
wrote:

> Thank you, Warren, for the review and ballot. I've replied inline below
> and put together this small PR with corresponding edits: https://github.
> com/danielfett/draft-dpop/pull/183/files
>
> On Tue, Apr 11, 2023 at 1:10 PM Warren Kumari via Datatracker  ietf.org> wrote:
>
>> Warren Kumari has entered the following ballot position for
>> draft-ietf-oauth-dpop-14: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/about/groups/iesg/statements/
>> handling-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> Thank you for writing this; I found it a fascinating and informative read.
>>
>
> Appreciate that! Thanks :)
>
>
>>
>> I don't have any particularly substantive comments, but I do have some
>> nits and
>> similar to hopefully further improve the document.
>>
>> 1: "These stolen artifacts can later be used together independent of the
>> client
>> application to access protected resources." -- I found this really hard to
>> parse. I think that some of it is the "used together independent"
>> formulation -
>> adding a comma would help, but I think just dropping "together" works even
>> better (it does say "artifacts" in plural, so that's already covered?)
>>
>
> Indeed that is really hard to parse. I agree with dropping the word
> "together".
>


Ta!


>
>
> 2: "Properly audience restricting access tokens can prevent such misuse" -
>> I
>> think that it would be helpful to reword this, or find a reference for
>> "audience restricting"
>>
>
> That sentence caught the ire of Éric Vyncke in his review/ballot and
> already had one attempt at improvement by me
> .
> But I can also add a reference, of sorts. I'm not aware of a good/easy
> reference for the concept of audience restricting but can point to the
> RFC7519 JWT `aud` claim as an example of .
>
>

Okey dokey, thanks.



>
>>
>> 3: Might it be worth adding a reference for XSS? I'm guessing that the
>> audience
>> will already be familiar, but if not,
>> https://owasp.org/www-community/attacks/xss/ ?
>>
>
> I feel like "cross-site scripting (XSS)" stands on its own okay and still
> gives an unfamiliar audience enough to search for more info.
>
>

Fair 'nuff.



> 4: Question: Why is the Nonce optional? Perhaps I missed it, but I was
>> unable
>> to find any discussion (I was expecting something in Sec 8,9 or 10)
>> providing
>> some reason why a server might not use a nonce (the closest I found was
>> "The
>> logic through which the server
>>makes that determination is out of scope of this document.", so I'm
>> guessing
>>that there *is* a reason, but... )
>>
>
> Long story short, the reason is basically that there's complexity and
> extra round trip costs in using it. And there were and are differing
> perceptions of its value in different circumstances.  The rough consensus
> was to leave its use (if/when/how) at the discretion of the server.
>


Okey dokey, works for me. Feel free to ignore this comment, but mentioning
that some implementations might choose not to use a nonce because of
"complexity and extra round trip costs" might be helpful for others like me
who were mystified.
(I really do mean feel free to ignore this, I won't be offended :-P)
W



>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Warren Kumari's No Objection on draft-ietf-oauth-dpop-14: (with COMMENT)

[Brian Campbell]

Thank you, Warren, for the review and ballot. I've replied inline below and
put together this small PR with corresponding edits:
https://github.com/danielfett/draft-dpop/pull/183/files

On Tue, Apr 11, 2023 at 1:10 PM Warren Kumari via Datatracker <
nore...@ietf.org> wrote:

> Warren Kumari has entered the following ballot position for
> draft-ietf-oauth-dpop-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for writing this; I found it a fascinating and informative read.
>

Appreciate that! Thanks :)


>
> I don't have any particularly substantive comments, but I do have some
> nits and
> similar to hopefully further improve the document.
>
> 1: "These stolen artifacts can later be used together independent of the
> client
> application to access protected resources." -- I found this really hard to
> parse. I think that some of it is the "used together independent"
> formulation -
> adding a comma would help, but I think just dropping "together" works even
> better (it does say "artifacts" in plural, so that's already covered?)
>

Indeed that is really hard to parse. I agree with dropping the word
"together".


2: "Properly audience restricting access tokens can prevent such misuse" - I
> think that it would be helpful to reword this, or find a reference for
> "audience restricting"
>

That sentence caught the ire of Éric Vyncke in his review/ballot and
already had one attempt at improvement by me
.
But I can also add a reference, of sorts. I'm not aware of a good/easy
reference for the concept of audience restricting but can point to the
RFC7519 JWT `aud` claim as an example of .




>
> 3: Might it be worth adding a reference for XSS? I'm guessing that the
> audience
> will already be familiar, but if not,
> https://owasp.org/www-community/attacks/xss/ ?
>

I feel like "cross-site scripting (XSS)" stands on its own okay and still
gives an unfamiliar audience enough to search for more info.


4: Question: Why is the Nonce optional? Perhaps I missed it, but I was
> unable
> to find any discussion (I was expecting something in Sec 8,9 or 10)
> providing
> some reason why a server might not use a nonce (the closest I found was
> "The
> logic through which the server
>makes that determination is out of scope of this document.", so I'm
> guessing
>that there *is* a reason, but... )
>

Long story short, the reason is basically that there's complexity and extra
round trip costs in using it. And there were and are differing perceptions
of its value in different circumstances.  The rough consensus was to leave
its use (if/when/how) at the discretion of the server.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth