[OAUTH-WG] [IANA #1270470] expert review for draft-ietf-oauth-dpop (jwt)

[Amanda Baber via RT]

Hi Hannes,

Can you also check this JWT registration before Thursday? John's an author, so 
we would need a review from you.

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-14#name-jwt-confirmation-methods-re

thanks,
Amanda

On Mon Apr 10 20:08:07 2023, david.dong wrote:
> Dear John and Hannes,
> 
> Hello. Have you had a chance to review these proposed registrations?
> 
> The due date is Wednesday April 12th, 2023, as this document is on
> this week's IESG telechat agenda.
> 
> Thank you very much for your time.
> 
> Best regards,
> 
> David Dong
> IANA Services Specialist
> 
> On Thu Apr 06 15:32:08 2023, david.dong wrote:
> > Dear John and Hannes (cc: oauth WG),
> >
> > As the designated experts for the JWT Confirmation Methods registry,
> > can you review the proposed registration in draft-ietf-oauth-dpop for
> > us? Please see:
> >
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
> >
> > The due date is Wednesday April 12th, 2023. This document is on next
> > week's IESG telechat agenda.
> >
> > -
> > Sixth, in the JWT Confirmation Methods registry on the JSON Web Token
> > (JWT) registry page located at:
> >
> > https://www.iana.org/assignments/jwt/
> >
> > a single, new registration will be made as follows:
> >
> > Confirmation Method Value: jkt
> > Confirmation Method Description: JWK SHA-256 Thumbprint
> > Change Controller: IETF
> > Specification Document(s): [ RFC-to-be; Section 6 ]
> >
> > As this section of the draft also requests a registration in a
> > Specification Required (see RFC 8126) registry, the IESG-designated
> > experts for the JWT Confirmation Methods registry have asked that you
> > send a review request to the mailing list specified in RFC7800. This
> > review must be completed before the document's IANA state can be
> > changed to "IANA OK."
> > -
> >
> > If this registration is OK, when the IESG approves the document for
> > publication, we'll make the registration at:
> >
> > https://www.iana.org/assignments/jwt/
> >
> > With thanks,
> >
> > David Dong
> > IANA Services Specialist

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [IANA #1270468] expert review for draft-ietf-oauth-dpop (oauth-parameters)

[Amanda Baber via RT]

Hi Justin,

Can you review this OAuth Dynamic Client Registration Metadata request before 
Thursday?

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-14#name-oauth-dynamic-client-regist

thanks,
Amanda

On Mon Apr 10 20:08:46 2023, david.dong wrote:
> Dear Justin,
> 
> Hello. Have you had a chance to review these proposed registrations?
> 
> The due date is Wednesday April 12th, 2023, as this document is on
> this week's IESG telechat agenda.
> 
> Thank you very much for your time.
> 
> Best regards,
> 
> David Dong
> IANA Services Specialist
> 
> On Thu Apr 06 15:22:17 2023, david.dong wrote:
> > Dear Justin (cc: oauth WG),
> >
> > As the designated expert for the OAuth Dynamic Client Registration
> > Metadata registry, can you review the proposed registration in draft-
> > ietf-oauth-dpop for us? Please see:
> >
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
> >
> > The due date is Wednesday April 12th, 2023. This document is on next
> > week's IESG telechat agenda.
> >
> > -
> > Eleventh, in the OAuth Dynamic Client Registration Metadata also on
> > the OAuth Parameters registry page located at:
> >
> > https://www.iana.org/assignments/oauth-parameters/
> >
> > a single, new parameter is to be registered as follows:
> >
> > Metadata Name: dpop_bound_access_tokens
> > Metadata Description: Boolean value specifying whether the client
> > always uses DPoP for token requests
> > Change Controller: IETF
> > Specification Document(s): [ RFC-to-be; Section 5.2 ]
> >
> > As this section of the draft also requests registrations in a
> > Specification Required (see RFC 8126) registry, the IESG-designated
> > experts for the OAuth Dynamic Client Registration Metadata registry
> > have asked that you send a review request to the mailing list
> > specified in RFC7591. This review must be completed before the
> > document's IANA state can be changed to "IANA OK."
> > -
> >
> > If this registration is OK, when the IESG approves the document for
> > publication, we'll make the registration at:
> >
> > https://www.iana.org/assignments/oauth-parameters/
> >
> > With thanks,
> >
> > David Dong
> > IANA Services Specialist

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [IANA #1270467] expert review for draft-ietf-oauth-dpop (oauth-parameters)

[Amanda Baber via RT]

Hi Hannes,

Can you check this one before Thursday? (We've also sent a separate JWT request 
to you and John.)

thanks,
Amanda

On Mon Apr 10 20:07:14 2023, david.dong wrote:
> Dear Hannes,
> 
> Hello. Have you had a chance to review these proposed registrations?
> 
> The due date is Wednesday April 12th, 2023, as this document is on
> this week's IESG telechat agenda.
> 
> Thank you very much for your time.
> 
> Best regards,
> 
> David Dong
> IANA Services Specialist
> 
> On Thu Apr 06 15:14:01 2023, david.dong wrote:
> > Dear Hannes,
> >
> > As the designated expert for the OAuth Access Token Types, OAuth
> > Extensions Error and OAuth Parameters registries, can you review the
> > proposed registration in draft-ietf-oauth-dpop for us? Please see:
> >
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
> >
> > The due date is Wednesday April 12th, 2023. This document is on next
> > week's IESG telechat agenda.
> >
> > -
> > First, in the OAuth Access Token Types registry:
> >
> > Name: DPoP
> > Additional Token Endpoint Response Parameters:
> > HTTP Authentication Scheme(s): DPoP
> > Change controller: IETF
> > Specification document(s): [ RFC-to-be ]
> >
> > Second, in the OAuth Extensions Error registry:
> >
> > Name: invalid_dpop_proof
> > Usage Location: token error response, resource error response
> > Protocol Extension: Demonstrating Proof of Possession (DPoP)
> > Change controller: IETF
> > Specification document(s): [ RFC-to-be ]
> >
> > Name: use_dpop_nonce
> > Usage Location: token error response, resource error response
> > Protocol Extension: Demonstrating Proof of Possession (DPoP)
> > Change controller: IETF
> > Specification document(s): [ RFC-to-be ]
> >
> > Third, in the OAuth Parameters registry:
> >
> > Name: dpop_jkt
> > Parameter Usage Location: authorization request
> > Change Controller: IETF
> > Reference: [ RFC-to-be; Section 10 ]
> > -
> >
> > If this registration is OK, when the IESG approves the document for
> > publication, we'll make the registration at:
> >
> > https://www.iana.org/assignments/oauth-parameters/
> >
> > With thanks,
> >
> > David Dong
> > IANA Services Specialist

___
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)

[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

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

[Warren Kumari via Datatracker]

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.

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?)

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"

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/ ?

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... )



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-selective-disclosure-jwt-04.txt

[Brian Campbell]

This -04 is a small update that fixes some issues with the description
of processing
of disclosures that were found in -03 (thanks to Filip and Christian).

-- Forwarded message -
From: 
Date: Tue, Apr 11, 2023 at 10:29 AM
Subject: [OAUTH-WG] I-D Action:
draft-ietf-oauth-selective-disclosure-jwt-04.txt
To: 
Cc: 



A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Web Authorization
Protocol (OAUTH) WG of the IETF.

   Title   : Selective Disclosure for JWTs (SD-JWT)
   Authors : Daniel Fett
 Kristina Yasuda
 Brian Campbell
   Filename: draft-ietf-oauth-selective-disclosure-jwt-04.txt
   Pages   : 70
   Date: 2023-04-11

Abstract:
   This document specifies conventions for creating JSON Web Token (JWT)
   documents that support selective disclosure of JWT claims.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Web Authorization
   Protocol Working Group mailing list (oauth@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/oauth/.

   Source for this draft and an issue tracker can be found at
   https://github.com/oauth-wg/oauth-selective-disclosure-jwt.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-04.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-selective-disclosure-jwt-04

Internet-Drafts are also available by rsync at rsync.ietf.org:
:internet-drafts


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

-- 
_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

[OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Web Authorization
Protocol (OAUTH) WG of the IETF.

   Title   : Selective Disclosure for JWTs (SD-JWT)
   Authors : Daniel Fett
 Kristina Yasuda
 Brian Campbell
   Filename: draft-ietf-oauth-selective-disclosure-jwt-04.txt
   Pages   : 70
   Date: 2023-04-11

Abstract:
   This document specifies conventions for creating JSON Web Token (JWT)
   documents that support selective disclosure of JWT claims.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Web Authorization
   Protocol Working Group mailing list (oauth@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/oauth/.

   Source for this draft and an issue tracker can be found at
   https://github.com/oauth-wg/oauth-selective-disclosure-jwt.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-04.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-selective-disclosure-jwt-04

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Eric Vyncke (evyncke)]

Thank you, Brian, for your prompt reply and the PR.

Your point about the tags around "none" is well taken.

Regards

-éric

From: Brian Campbell 
Date: Tuesday, 11 April 2023 at 16:11
To: Eric Vyncke 
Cc: The IESG , "draft-ietf-oauth-d...@ietf.org" 
, "oauth-cha...@ietf.org" 
, "oauth@ietf.org" , 
"rifaat.s.i...@gmail.com" 
Subject: Re: Éric Vyncke's No Objection on draft-ietf-oauth-dpop-14: (with 
COMMENT)

Thanks for the review and ballot Éric. I've replied inline below and put 
together this PR with corresponding edits: 
https://github.com/danielfett/draft-dpop/pull/182/files

On Mon, Apr 10, 2023 at 11:45 PM Éric Vyncke via Datatracker 
mailto:nore...@ietf.org>> wrote:
Éric Vyncke 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 the work put into this document.

Please find below some non-blocking COMMENT points, and some nits.

Special thanks to Rifaat Shekh-Yusef for the shepherd's detailed write-up
including the WG consensus (and the author count) even if the justification of
the intended status is rather light.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non blocking)

## Section 1

Should there be a reference to OAuth ?

Sure, we'll add a RFC6749 reference with OAuth in that first sentence in 
Section 1.


s/The mechanism described herein /The mechanism specified herein / ? as it is
proposed standard

Makes sense. We'll update.


Adding a short description of SPA would be useful, or simply remove this
reference ?

I'll try to rephrase that sentence somewhat to be more descriptive.



# NITS (non blocking / cosmetic)

## Section 2

` Properly audience restricting access tokens can prevent such misuse` is
difficult to parse

I'll try to tighten it up.


## Section 4.1

s/repeated below for ease of reference/repeated below in figure 3 for ease of
reference/ ?

Sure, I'll change to ref figure 3.


## Section 4.2

s/MUST NOT be none or an identifier for a symmetric algorithm (MAC)/MUST NOT be
'none' or an identifier for a symmetric algorithm/

  "none" is wrapped in a  tag in the HTML/HTMLized versions of the 
draft, which is consistent with treatment of other JWS algorithm literals in 
the document.



## Section 6.1

`JSON Web Tokens (JWT)` the JWT acronym has already been defined.

 Good point. I'll just use the acronym there.

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] Éric Vyncke's No Objection on draft-ietf-oauth-dpop-14: (with COMMENT)

[Brian Campbell]

Thanks for the review and ballot Éric. I've replied inline below and put
together this PR with corresponding edits:
https://github.com/danielfett/draft-dpop/pull/182/files

On Mon, Apr 10, 2023 at 11:45 PM Éric Vyncke via Datatracker <
nore...@ietf.org> wrote:

> Éric Vyncke 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 the work put into this document.
>
> Please find below some non-blocking COMMENT points, and some nits.
>
> Special thanks to Rifaat Shekh-Yusef for the shepherd's detailed write-up
> including the WG consensus (and the author count) even if the
> justification of
> the intended status is rather light.
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> # COMMENTS (non blocking)
>
> ## Section 1
>
> Should there be a reference to OAuth ?
>

Sure, we'll add a RFC6749 reference with OAuth in that first sentence in
Section 1.


>
> s/The mechanism described herein /The mechanism specified herein / ? as it
> is
> proposed standard
>

Makes sense. We'll update.


>
> Adding a short description of SPA would be useful, or simply remove this
> reference ?
>

I'll try to rephrase that sentence somewhat to be more descriptive.



# NITS (non blocking / cosmetic)
>
> ## Section 2
>
> ` Properly audience restricting access tokens can prevent such misuse` is
> difficult to parse
>

I'll try to tighten it up.



> ## Section 4.1
>
> s/repeated below for ease of reference/repeated below in figure 3 for ease
> of
> reference/ ?
>

Sure, I'll change to ref figure 3.


>
> ## Section 4.2
>
> s/MUST NOT be none or an identifier for a symmetric algorithm (MAC)/MUST
> NOT be
> 'none' or an identifier for a symmetric algorithm/
>

  "none" is wrapped in a  tag in the HTML/HTMLized versions of
the draft, which is consistent with treatment of other JWS algorithm
literals in the document.



>
> ## Section 6.1
>
> `JSON Web Tokens (JWT)` the JWT acronym has already been defined.
>

 Good point. I'll just use the acronym there.

-- 
_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