[OAUTH-WG] Re: [Technical Errata Reported] RFC7519 (8060)

[Brian Campbell]

I can absolutely appreciate the "make it worth my while to wrestle w/
the RFC errata system " sentiment but am not in a position myself to spend
more time on errata right now.

On Tue, Feb 11, 2025 at 4:10 AM Deb Cooley  wrote:

> Can I talk you into looking at the other three reported errata on that
> RFC?  (RFC 7519 and Erratas:  5906, 7720, and 8225)
> To make it worth my while to wrestle w/ the RFC errata system...
>
> Deb
>
> On Mon, Feb 10, 2025 at 5:56 PM Brian Campbell 
> wrote:
>
>> Pieter said errata in July of last year and we've had this very
>> intermittent conversation about https://www.rfc-editor.org/errata/eid8060
>> in the intervening months. I think it's ready for those edits and button
>> pushing you mentioned. No impact on RFCs 7797 or 8725 (BCP 225). These are
>> the edits I think we've agreed on as validated/verified technical errata:
>>
>> Section 7.2 says:
>>
>>5.  Verify that the resulting JOSE Header includes only parameters
>> and values whose syntax and semantics are both understood and
>> supported or that are specified as being ignored when not
>> understood.
>>
>> It should say:
>>
>>5.  Verify the resulting JOSE Header according to RFC7515 or RFC7516.
>>
>> Notes:
>> Validation step 5 in section 7.2 of RFC 7519 states that header
>> parameters should only be ignored if they are explicitly specified as
>> needing to be ignored.
>>
>> This is contrary to step 7 in section 7.2 of RFC 7519 which requires that
>> the processing rules of RFC 7515 should be followed if the JWT is a JWS, or
>> the rules of RFC7516 should be followed if the JWT is a JWE. Neither RFC
>> 7515 nor RFC 7516 include any special provisions for only ignoring header
>> parameters if they are specified as being ignored, but instead requires all
>> header parameters to be ignored if they are not understood, except if they
>> are critical.
>>
>>
>>
>>
>>
>> On Sat, Feb 8, 2025 at 4:37 AM Deb Cooley  wrote:
>>
>>> Errata?  Did I hear you say errata?
>>>
>>> I can push the buttons to properly dispatch this.  I think this includes
>>> editing an errata and certainly includes adding notes to it.  I need to
>>> know what edits and or comments you want made, and what outcome (reject,
>>> validate, hold for document update).  Also how it affects RFCs 7797 and
>>> 8725 (BCP 225), since I see that 7519 is updated by these.
>>>
>>> While we are doing this work, there are three others (5906, 7720, and
>>> 8225) at:
>>> https://www.rfc-editor.org/errata_search.php?rfc=7519&rec_status=2&area_acronym=sec&presentation=table
>>> .  Take a peek and tell me how to mark them (reject, validate, HFDU).  The
>>> tooling for this is, h old, so I like to do these in groups.
>>>
>>> If there is appetite, we can look at other oauth errata...
>>>
>>> Deb
>>>
>>>
>>>
>>> On Fri, Feb 7, 2025 at 2:56 PM Brian Campbell >> 40pingidentity@dmarc.ietf.org> wrote:
>>>
 Apologies Pieter, this fell "below the fold" in my inbox so to speak
 and I lost track of responding to it. Thanks for the proposed new "notes"
 for the errata, which I do think are sufficient now. In conjunction with
 that simple "corrected text" you had of "5.  Verify the resulting JOSE
 Header according to RFC7515 or RFC7516."

 On Thu, Nov 21, 2024 at 8:25 PM Pieter Kasselman 
 wrote:

> Brian, as discussed at IETF 121, it would be good to wrap up on this 
> errata. Is the below sufficient, or are there additional refinements or 
> steps to take?
>
> Cheers
>
> Pieter
>
> 
>
> Hi Brian, agreed, and thanks for pointing that out. Suggestion below:
>
>
>
> Notes
> -
> Validation step 5 in section 7.2 of RFC 7519 states that header 
> parameters should only be ignored if they are explicitly specified as 
> needing to be ignored.
>
> This is contrary to step 7 in section 7.2 of RFC 7519 which requires that 
> the processing rules of RFC 7515 should be followed if the JWT is a JWS, 
> or the rules of RFC7516 should be followed if the JWT is a JWE. Neither 
> RFC 7515 nor RFC 7516 include any special provisions for only ignoring 
> header parameters if they are specified as being ignored, but instead 
> requires all header parameters to be ignored if they are not understood, 
> except if they are critical.
>
> This errata clarifies that JOSE Header parameters should be verified 
> according to RFC7515 (JWS) or RFC7516 (JWE).
>
>
>
>
> From: Brian Campbell  
> <>
> Sent: Monday 12 August 2024 19:46
> To: Pieter Kasselman  
> <>
> Cc: David Waite  
> <>; Paul Wouters 
>  <>; RFC Errata 
> System  <>; 
> prkassel...@gmail.com; oauth@ietf.org
> Sub

[OAUTH-WG] Re: [Technical Errata Reported] RFC7519 (8060)

[Deb Cooley]

Can I talk you into looking at the other three reported errata on that
RFC?  (RFC 7519 and Erratas:  5906, 7720, and 8225)
To make it worth my while to wrestle w/ the RFC errata system...

Deb

On Mon, Feb 10, 2025 at 5:56 PM Brian Campbell 
wrote:

> Pieter said errata in July of last year and we've had this very
> intermittent conversation about https://www.rfc-editor.org/errata/eid8060
> in the intervening months. I think it's ready for those edits and button
> pushing you mentioned. No impact on RFCs 7797 or 8725 (BCP 225). These are
> the edits I think we've agreed on as validated/verified technical errata:
>
> Section 7.2 says:
>
>5.  Verify that the resulting JOSE Header includes only parameters
> and values whose syntax and semantics are both understood and
> supported or that are specified as being ignored when not
> understood.
>
> It should say:
>
>5.  Verify the resulting JOSE Header according to RFC7515 or RFC7516.
>
> Notes:
> Validation step 5 in section 7.2 of RFC 7519 states that header parameters
> should only be ignored if they are explicitly specified as needing to be
> ignored.
>
> This is contrary to step 7 in section 7.2 of RFC 7519 which requires that
> the processing rules of RFC 7515 should be followed if the JWT is a JWS, or
> the rules of RFC7516 should be followed if the JWT is a JWE. Neither RFC
> 7515 nor RFC 7516 include any special provisions for only ignoring header
> parameters if they are specified as being ignored, but instead requires all
> header parameters to be ignored if they are not understood, except if they
> are critical.
>
>
>
>
>
> On Sat, Feb 8, 2025 at 4:37 AM Deb Cooley  wrote:
>
>> Errata?  Did I hear you say errata?
>>
>> I can push the buttons to properly dispatch this.  I think this includes
>> editing an errata and certainly includes adding notes to it.  I need to
>> know what edits and or comments you want made, and what outcome (reject,
>> validate, hold for document update).  Also how it affects RFCs 7797 and
>> 8725 (BCP 225), since I see that 7519 is updated by these.
>>
>> While we are doing this work, there are three others (5906, 7720, and
>> 8225) at:
>> https://www.rfc-editor.org/errata_search.php?rfc=7519&rec_status=2&area_acronym=sec&presentation=table
>> .  Take a peek and tell me how to mark them (reject, validate, HFDU).  The
>> tooling for this is, h old, so I like to do these in groups.
>>
>> If there is appetite, we can look at other oauth errata...
>>
>> Deb
>>
>>
>>
>> On Fri, Feb 7, 2025 at 2:56 PM Brian Campbell > 40pingidentity@dmarc.ietf.org> wrote:
>>
>>> Apologies Pieter, this fell "below the fold" in my inbox so to speak and
>>> I lost track of responding to it. Thanks for the proposed new "notes" for
>>> the errata, which I do think are sufficient now. In conjunction with that
>>> simple "corrected text" you had of "5.  Verify the resulting JOSE Header
>>> according to RFC7515 or RFC7516."
>>>
>>> On Thu, Nov 21, 2024 at 8:25 PM Pieter Kasselman 
>>> wrote:
>>>
 Brian, as discussed at IETF 121, it would be good to wrap up on this 
 errata. Is the below sufficient, or are there additional refinements or 
 steps to take?

 Cheers

 Pieter

 

 Hi Brian, agreed, and thanks for pointing that out. Suggestion below:



 Notes
 -
 Validation step 5 in section 7.2 of RFC 7519 states that header parameters 
 should only be ignored if they are explicitly specified as needing to be 
 ignored.

 This is contrary to step 7 in section 7.2 of RFC 7519 which requires that 
 the processing rules of RFC 7515 should be followed if the JWT is a JWS, 
 or the rules of RFC7516 should be followed if the JWT is a JWE. Neither 
 RFC 7515 nor RFC 7516 include any special provisions for only ignoring 
 header parameters if they are specified as being ignored, but instead 
 requires all header parameters to be ignored if they are not understood, 
 except if they are critical.

 This errata clarifies that JOSE Header parameters should be verified 
 according to RFC7515 (JWS) or RFC7516 (JWE).




 From: Brian Campbell  
 <>
 Sent: Monday 12 August 2024 19:46
 To: Pieter Kasselman  
 <>
 Cc: David Waite  
 <>; Paul Wouters 
  <>; RFC Errata System 
  <>; 
 prkassel...@gmail.com; oauth@ietf.org
 Subject: Re: [OAUTH-WG] Re: [Technical Errata Reported] RFC7519 (8060)

 Thanks Pieter,

 That sounds good to me. I think a bit of the explanatory text in the 
 "Notes" part of the errata likely needs to be adjusted accordingly too.



 On Mon, Aug 12, 2024 at 5:01 AM Pieter Kasselman 
 mailto:40microsoft@dmarc.iet

[OAUTH-WG] Review comments for SD-JWT

[Hannes Tschofenig]

Hi Daniel, Kristina, Brian,

here are a few review comments that are easy to address:

1. Complete the IANA registry section for the media type registrations. 
Search for TBD in that section. As you make this change you might also 
want to remove the RFC 2119 language from the description fields. I do 
not believe it is the right place to put normative language.


2. Normative Reference: I think you need to move RFC 8725, RFC5234, and 
RFC6838 from the informative reference section to the normative section 
since they are needed for the specification. RFC 8725 is probably a 
reference we can argue about but the others seem to be pretty clear cases.


3. Minor nits:

In the introduction you write: "instead, a hash digest of the data takes 
its place.". Since the digest is computed using a hash, it would be 
better to just say "digest" instead of "hash digest". This would also be 
consistent with the rest of the document.


In Section 4.1, you write: "The payload MUST NOT contain the reserved 
claims _sd or ... except for the purpose of transporting digests as 
described below.". The term "reserved claim" only appears once in the 
document and it is not clear to me whether the "..." refers to the claim 
with the name "..." or whether you are referring to the claims that this 
document defines. The exception also appears misleading since you 
defined the claims for conveying digests. The reference to "below" in 
this sentence is not helping since I do not really know where to look at.


In Section 4.2.1, you write:  "The claim value, as it would be used in a 
regular JWT payload. The value MAY be of any type that is allowed in 
JSON, including numbers, strings, booleans, arrays, null, and objects.". 
I believe you should write "The value MUST be of a type that is allowed 
in JSON". The sentence appears more than once in the document.


In Section 9.1 you write: "The Issuer-signed JWT MUST be signed by the 
Issuer to protect integrity of the issued claims.". I would remove the 
first "Issuer-signed" qualification to improve the readability of the 
sentence.


In Section 9.4, you write: "In the terminology of cryptographic 
commitment schemes, the hash function MUST be computationally hiding.". 
Since you mention the terminology, I expected a reference to the term, 
especially given the use of RFC 2119 language.


Section 9.8 is called "Issuer Signature Key Distribution and Rotation". 
It should instead be called "Issuer Signature Verification Key 
Distribution" since you are not planning to distribute the signature key 
of the issuer itself since it is the private key.


In Section 10.1, you write "The following types of unlinkability are 
considered here:". I would change this to "The following types of 
unlinkability are discussed below:"


I noticed the absence of a mention regarding the use of digital 
signatures in Verifier/Verifier unlinkability. If a holder uses SD-JWTs 
with different Verifiers, these SD-JWTs are linkable based on the 
signature value, unless each SD-JWT is signed by the Issuer 
individually. Batch issuance is suggested as a solution when the Holder 
does not request SD-JWTs individually- either proactively or in 
real-time. Proactively requesting SD-JWTs works in cases where the 
holder knows in advance what disclosures the Verifier will ask for. 
However, if there are many possible combinations, this approach may 
become practically challenging. If the holder switches to a real-time 
request pattern with the Issuer, the SD-JWT solution may become less 
useful since the Holder can just ask the Issuer for a regular JWT that 
only contains the claims it wants to disclose to the Verifier. Do the 
existing media types support returning multiple SD-JWTs and multiple 
SD-JWT+KBs in a batch?


In Section 11, you acknowledge Richard Barnes and Martin Thomson. I 
suggest removing the "fnord" from Richard "fnord" Barnes and the 
paragraph related to Martin Thomson:


"
   Special appreciation is extended to Martin Thomson, who wielded his
   considerable intellect and influence to change a single occurrence of
   the word "to" to "with" in the midst of a significant proposal that
   would be integrated into this document six months later.
"

I would also acknowledge Denis, even though his feedback was not 
incorporated into the document. He certainly reviewed the document.


In the body of the document, you mention "credential" several times. It 
might be helpful to clarify in the terminology section that this term is 
a synonym for SD-JWT and SD-JWT+KB. In the appendix the term Verifiable 
Credential is used a few times but in the body of the document you just 
use the term "credential". I believe that "credential" and "Verifiable 
Credential" are used interchangeably.


Ciao
Hannes


___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - RFC7523bis

[Dominick Baier]

 I support adoption.


On 7. February 2025 at 20:51:43, Michael Jones (michael_b_jo...@hotmail.com)
wrote:

I obviously am in favor of adoption, as I believe we should do the work to
close the identified security vulnerabilities in a timely manner.  Thanks
to all who worked on this doc with me prior to last week’s interim meeting.



I responded to Brian’s critiques in the thread “Re: [OAUTH-WG] Re:
draft-jones-oauth-rfc7523bis published and questions to the working group”.



-- Mike



*From:* Brian Campbell 
*Sent:* Friday, February 7, 2025 11:12 AM
*To:* Rifaat Shekh-Yusef 
*Cc:* oauth 
*Subject:* [OAUTH-WG] Re: Call for adoption - RFC7523bis



As stated in the "[OAUTH-WG] Re: draft-jones-oauth-rfc7523bis published and
questions to the working group
"
thread - I don't believe this draft is the right starting point.



But if the WG decides otherwise, I sincerely hope that changes to
appropriately focus the scope of the draft are made.



On Thu, Feb 6, 2025 at 4:37 PM Rifaat Shekh-Yusef 
wrote:

All,

This is a call for adoption for the *RFC7523bis* draft that was discussed
recently during the last interim meeting:
https://datatracker.ietf.org/doc/draft-jones-oauth-rfc7523bis/

Remember that *adoption* does *not* mean a document is *finished*, only
that it is an *acceptable starting point*.

Please, reply on the mailing list and let us know if you are in favor or
against adopting this draft as WG document, by Feb 21st.

Regards,
 Rifaat & Hannes

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org


*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
To unsubscribe send an email to oauth-le...@ietf.org
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - RFC7523bis

[Brock Allen]

Agreed -- I also support adoption. 


-Brock

On 2/11/2025 10:20:35 AM, Dominick Baier  wrote:
I support adoption.


On 7. February 2025 at 20:51:43, Michael Jones (michael_b_jo...@hotmail.com 
[mailto:michael_b_jo...@hotmail.com]) wrote:
I obviously am in favor of adoption, as I believe we should do the work to 
close the identified security vulnerabilities in a timely manner.  Thanks to 
all who worked on this doc with me prior to last week’s interim meeting.
 
I responded to Brian’s critiques in the thread “Re: [OAUTH-WG] Re: 
draft-jones-oauth-rfc7523bis published and questions to the working group”.
 
    -- Mike
 
From: Brian Campbell mailto:40pingidentity@dmarc.ietf.org]>
Sent: Friday, February 7, 2025 11:12 AM
To: Rifaat Shekh-Yusef mailto:rifaat.s.i...@gmail.com]>
Cc: oauth mailto:oauth@ietf.org]>
Subject: [OAUTH-WG] Re: Call for adoption - RFC7523bis
 
As stated in the "[OAUTH-WG] Re: draft-jones-oauth-rfc7523bis published and 
questions to the working group 
[https://mailarchive.ietf.org/arch/msg/oauth/rZBbsr3TXkgK5bCrxRpdiRv2QVU/]"; 
thread - I don't believe this draft is the right starting point.
 
But if the WG decides otherwise, I sincerely hope that changes to appropriately 
focus the scope of the draft are made.  
 
On Thu, Feb 6, 2025 at 4:37 PM Rifaat Shekh-Yusef mailto:rifaat.s.i...@gmail.com]> wrote:
All,

This is a call for adoption for the RFC7523bis draft that was discussed 
recently during the last interim meeting:
https://datatracker.ietf.org/doc/draft-jones-oauth-rfc7523bis/ 
[https://datatracker.ietf.org/doc/draft-jones-oauth-rfc7523bis/]

Remember that adoption does not mean a document is finished, only that it is an 
acceptable starting point.

Please, reply on the mailing list and let us know if you are in favor or 
against adopting this draft as WG document, by Feb 21st.

Regards,
 Rifaat & Hannes
___
OAuth mailing list -- oauth@ietf.org [mailto:oauth@ietf.org]
To unsubscribe send an email to oauth-le...@ietf.org 
[mailto:oauth-le...@ietf.org]

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 [mailto:oauth@ietf.org]
To unsubscribe send an email to oauth-le...@ietf.org 
[mailto:oauth-le...@ietf.org]

___ OAuth mailing list -- 
oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org