[OAUTH-WG] Re: IPR Disclosure - Selective Disclosure for JWTs (SD-JWT)

[Hannes Tschofenig]

Brian, Daniel, Kristina,

is it correct that you are willing to be listed as a document author?

Ciao
Hannes


Am 09.02.2025 um 16:02 schrieb Brian Campbell:

Thanks Hannes,

I am not aware of any IPR associated with the document.

On Sun, Feb 9, 2025 at 6:59 AM Hannes Tschofenig 
 wrote:


Hi Daniel, Kristina, Brian

as part of the shepherd write-up, all authors of

must confirm that any and all appropriate IPR disclosures required
for full
conformance with the provisions of BCP 78 and BCP 79 have been filed.

Please, reply to this email, on the mailing list, and indicate if
you are
aware of any IPRs associated with this document.

Please also indicate your willingness to be listed as a document
author.

Ciao
Hannes
(Document Shepherd)

___
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-WG] Re: IPR Disclosure - Selective Disclosure for JWTs (SD-JWT)

[Daniel Fett]

Yes, of course :-)

-Daniel

Am 10.02.25 um 13:03 schrieb Hannes Tschofenig:

Brian, Daniel, Kristina,

is it correct that you are willing to be listed as a document author?

Ciao
Hannes


Am 09.02.2025 um 16:02 schrieb Brian Campbell:

Thanks Hannes,

I am not aware of any IPR associated with the document.

On Sun, Feb 9, 2025 at 6:59 AM Hannes Tschofenig 
 wrote:


    Hi Daniel, Kristina, Brian

    as part of the shepherd write-up, all authors of
    
    must confirm that any and all appropriate IPR disclosures required
    for full
    conformance with the provisions of BCP 78 and BCP 79 have been 
filed.


    Please, reply to this email, on the mailing list, and indicate if
    you are
    aware of any IPRs associated with this document.

    Please also indicate your willingness to be listed as a document
    author.

    Ciao
    Hannes
    (Document Shepherd)

    ___
    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: IPR Disclosure - Selective Disclosure for JWTs (SD-JWT)

[Brian Campbell]

Yes, of course.

On Mon, Feb 10, 2025 at 5:26 AM Daniel Fett  wrote:

> Yes, of course :-)
>
> -Daniel
> Am 10.02.25 um 13:03 schrieb Hannes Tschofenig:
>
> Brian, Daniel, Kristina,
>
> is it correct that you are willing to be listed as a document author?
>
> Ciao
> Hannes
>
>
> Am 09.02.2025 um 16:02 schrieb Brian Campbell:
>
> Thanks Hannes,
>
> I am not aware of any IPR associated with the document.
>
> On Sun, Feb 9, 2025 at 6:59 AM Hannes Tschofenig
>   wrote:
>
> Hi Daniel, Kristina, Brian
>
> as part of the shepherd write-up, all authors of
> 
> must confirm that any and all appropriate IPR disclosures required
> for full
> conformance with the provisions of BCP 78 and BCP 79 have been filed.
>
> Please, reply to this email, on the mailing list, and indicate if
> you are
> aware of any IPRs associated with this document.
>
> Please also indicate your willingness to be listed as a document
> author.
>
> Ciao
> Hannes
> (Document Shepherd)
>
> ___
> 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
>

-- 
_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-WG] Re: IPR Disclosure - Selective Disclosure for JWTs (SD-JWT)

[Kristina Yasuda]

many times yes!
Thank you, Hannes.

On Mon, Feb 10, 2025 at 2:20 PM Brian Campbell  wrote:

> Yes, of course.
>
> On Mon, Feb 10, 2025 at 5:26 AM Daniel Fett  40danielfett...@dmarc.ietf.org> wrote:
>
>> Yes, of course :-)
>>
>> -Daniel
>> Am 10.02.25 um 13:03 schrieb Hannes Tschofenig:
>>
>> Brian, Daniel, Kristina,
>>
>> is it correct that you are willing to be listed as a document author?
>>
>> Ciao
>> Hannes
>>
>>
>> Am 09.02.2025 um 16:02 schrieb Brian Campbell:
>>
>> Thanks Hannes,
>>
>> I am not aware of any IPR associated with the document.
>>
>> On Sun, Feb 9, 2025 at 6:59 AM Hannes Tschofenig
>>   wrote:
>>
>> Hi Daniel, Kristina, Brian
>>
>> as part of the shepherd write-up, all authors of
>> 
>> must confirm that any and all appropriate IPR disclosures required
>> for full
>> conformance with the provisions of BCP 78 and BCP 79 have been filed.
>>
>> Please, reply to this email, on the mailing list, and indicate if
>> you are
>> aware of any IPRs associated with this document.
>>
>> Please also indicate your willingness to be listed as a document
>> author.
>>
>> Ciao
>> Hannes
>> (Document Shepherd)
>>
>> ___
>> 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
>>
>
> *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] late review of draft-ietf-oauth-selective-disclosure-jwt-15

[Rohan Mahy]

Hi,
Today I did a full read and review of
draft-ietf-oauth-selective-disclosure-jwt-15. Below are my comments.
Thanks,
-rohan

Overall

   - I found the Introduction, and Sections 2 and 3, not concrete enough to
   follow what is being discussed in a first read through. I proposed a new
   Section 1.3 which I think has the right spirit.
   - I am super happy that we are not using did: URIs in the document.
   - I  think it is very useful to have a capitalized name for the digests.
   I suggest Blinded Hash. Another good choice is Redacted Claim Hash.
   - All the SHOULD statements should explain why they are not MUSTs or
   under what circumstances the implementer could do something different that
   still makes sense.
   - If a validity claim (ex: exp, nbf) is redacted, does it need to be
   validated if the relevant disclosure is provided?


Abstract
suggestion: s/for the selective disclosure of individual elements of a
JSON-encoded data structure used as the payload of a JSON Web Signature
(JWS)/for the selective disclosure of individual elements of a JSON-encoded
JSON Web Signature (JWS) payload/
Intro:
suggestion: s/A new model is emerging that/Another model/
Section 1.1
suggestions:
s/SD-JWT is a composite structure enabling selective disclosure of its
contents/SD-JWT is a composite structure, consisting of a JWS plus optional
disclosures, enabling selective disclosure of portions of the JWS payload.
s/SD-JWT+KB is a composite structure enabling cryptographic key binding
when presented to the Verifier./SD-JWT+KB is a composite structure of an
SD-JWT and a cryptographic key binding that can be presented to and
verified by the Verifier./
Section 1.2
Selective Disclosure: "JWT Claims Set" is used in a definition but not yet
defined. Since the definition in RFC7519 is somewhat circular, maybe s/JWT
Claims Set/JWS payload/
Selectively Disclosable JWT: s/Issuer-signed JWT (JWS,
[RFC7515])/Issuer-signed JWS [RFC7515] (often a JWT)/
Disclosure: s/The Disclosure is used to calculate a digest for the
respective claim.//
*add:* Blinded Hash: The cryptographic digest (hash) of a specific
Disclosure
Key Binding JWT (KB-JWT): s/A Key Binding JWT is said to "be tied to" a
particular SD-JWT when its payload is signed using the key included in the
SD-JWT payload, and also contains a hash of the SD-JWT in its sd_hash
claim. A JWT for proving Key Binding as defined in Section 4.3
./A
Key Binding JWT is said to "be tied to" a particular SD-JWT when the KB-JWT
is signed using the key included in the SD-JWT payload, and the KB-JWT
contains a hash of the SD-JWT in its sd_hash claim. Its format is defined
in Section 4.3

./
maybe mention here that "JSON object property" is just the (truly horrible)
JSON name for a map/dict key and value.

*I think it is a wasted opportunity to not show an example of the structure
in the Introduction!* For example:
Section 1.3 Brief Illustration
The JWS structure consists of protected headers, the payload, and a
signature. The structure can be represented in JWS Compact Serialization
(the most common) or JWS JSON Serialization. In compact serialization, a
base64url encoded version of the three components are concatenated,
separated by periods. In the compact representation of an SD-JWT, this is
followed by a tilde character, and a list of base64url encoded disclosure
strings separated by tildes. If key binding is used, the KB-JWT follows the
last tilde.

Issuer-signed JWS
..

SD-JWT
~~~...~~

SD-JWT+KB
~~~...~~

The decoded payload below (from an example in Section 5.1 with parts elided
for brevity with ) contains the following:

   - the _sd claim (which contains Blinded Hashes),
   - standard JWT claims (issuer, issued at time, expiration, subscriber),
   and
   - the public key of the holder in a confirmation (cnf ) claim.

{
   "_sd": [
  
  "JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE",
  "PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI",
  "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo",
  
   ],
   "iss": "https://issuer.example.com";,
   "iat": 168300,
   "exp": 188300,
   "sub": "user_42",
  
   "_sd_alg": "sha-256",
   "cnf": {
 "jwk": {
   "kty": "EC",
   "crv": "P-256",
   "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
   "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
}
   }
}

Assuming an SD-JWT presented to a Verifier with decoded payload shown above
and a disclosure string
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRvZSJd, the
verifier would take the digest of the disclosure string using the SHA256
algorithm from the _sd_hash claim and find that digest (
TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo) in the decoded payload. The
Verifier would base64url decode the disclosure into the salt, the claim
name, and the claim value:
["eluV5O

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

[Brian Campbell]

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.ietf.org>>
>>>  wrote:
>>> Thanks David and Brian.
>>>
>>> Unless there are any concerns with adopting the alternative text, I would 
>>> suggest the following for the errata in section 7.2 bullet 5:
>>>
>>> Original Text
>>> -
>>>5.   Verify that the resulting JOSE Header includes only parameters
>>> and values whose syntax and semantics are both understood and
>>>