[OAUTH-WG] [IANA #1416059] expert review for draft-ietf-oauth-selective-disclosure-jwt (media-type-structured-suffix)

[David Dong via RT]

Dear Alexey Melnikov, Darrel Miller (cc: oauth WG),

As the designated experts for the Structured Syntax Suffixes registry, can you 
review the proposed registration in 
draft-ietf-oauth-selective-disclosure-jwt-17 for us? Please see:

https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/

The due date is April 16th.

If this is OK, when the IESG approves the document for publication, we'll make 
the registration at:

https://www.iana.org/assignments/media-type-structured-suffix/

Unless you ask us to wait for the other reviewer, we’ll act on the first 
response we receive.

With thanks,

David Dong
IANA Services Sr. Specialist

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

[OAUTH-WG] [Errata Verified] RFC7519 (8060)

[RFC Errata System]

The following errata report has been verified for RFC7519,
"JSON Web Token (JWT)". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8060

--
Status: Verified
Type: Technical

Reported by: Pieter Kasselman 
Date Reported: 2024-07-31
Verified by: Deb Cooley (IESG)

Section: 7.2

Original Text
-
   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.

Corrected Text
--
   5.   Verify that 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 which requires that the processing 
rules of RFC 1515 be used if the JWT is a JWS (defined in RFC 1515). RFC 7515 
does not 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 (repeated below for convenience). 

"Unless listed as a critical Header Parameter, per
   Section 4.1.11, all Header Parameters not defined by this
   specification MUST be ignored when not understood."

A discussion with the authors at IETF 120 confirmed that all header parameters 
that are not understood must be ignored.

The proposed errata aims to clarify that if the JWT is a JWS, the processing 
rules of RFC 7151 should apply (including ignoring header parameters that are 
not understood). This is consistent with point 7.2, which requires that RFC 
7515 [JWS] rules applies and avoids the impression that a new requirement on 
when parameters are ignored is being introduced in (i.e. the need to be 
explicitly defined as needing to be ignored).

--
RFC7519 (draft-ietf-oauth-json-web-token-32)
--
Title   : JSON Web Token (JWT)
Publication Date: May 2015
Author(s)   : M. Jones, J. Bradley, N. Sakimura
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Stream  : IETF
Verifying Party : IESG

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

[OAUTH-WG] Re: [Last-Call] draft-ietf-oauth-selective-disclosure-jwt non-selectively disclosable claims

[Brian Campbell]

thanks Chad, I put in
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/563 so as
not to lose track of this

On Thu, Apr 3, 2025 at 7:19 AM Chad Parry  wrote:

> The phrase "non-selectively disclosable claims" confused me. At first I
> interpreted it to mean "claims that are disclosable but not in a
> selective way." The intended reading is "claims that are not selectively
> disclosable." The ambiguity is between "(non-selectively) disclosable
> claims" and "non-(selectively disclosable) claims." I believe that the
> phrase would be clarified by punctuating it "non-selectively-disclosable
> claims." An adverb ending in "ly" does not normally get hyphenated in
> compound phrases, but this is different because of the ambiguity.
> Alternatively, invent a new phrase like "permanently disclosed claims"
> or "unconditionally disclosed claims" that can't be misinterpreted.
>
> Also, section 9.6 uses the phrase "not disclosable," which sounds like a
> name that will never get disclosed. I think it means
> "non-selectively-disclosable." The entire section, with the word
> "blinding" that is not used anywhere else, looks like an unnecessary
> holdover from old versions of the document.
>
> --
> last-call mailing list -- last-c...@ietf.org
> To unsubscribe send an email to last-call-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: [IANA #1416058] expert review for draft-ietf-oauth-selective-disclosure-jwt (jwt)

[Brian Campbell]

Thanks Filip,

I think your observations about "..." are correct. It doesn't necessarily
need to be registered and isn't even strictly speaking a claim name. We
talked about this some (poorly captured in this issue /315
)
and decided it'd be a reasonable idea to request to register it anyway. I
think the motivation was largely to have it documented in a place, other
than the draft itself, where people might maybe look for such information
and to prevent it from being used as a top level claim name. Also (other
than having this conversation, which was anticipated) there didn't seem to
be any real downside to requesting registration. And there's not, as far as
I know, definitive guidance or precedent.

Having said that, however, I don't think there's a lot of conviction behind
it from anyone involved. And not requesting / making the registration for
"..." would be a perfectly reasonable outcome too.


On Thu, Apr 3, 2025 at 8:39 AM Filip Skokan  wrote:

> Hello David, SD-JWT authors,
>
> I have reviewed the proposed registrations in
> draft-ietf-oauth-selective-disclosure-jwt-17
> 
> .
>
>- *"_sd"* - OK *✓*
>- *"_sd_alg"* - OK *✓*
>- *"sd_hash"* - OK *✓* (after digging out the discussion around why
>"sd_hash" does not have a prefix (issues/371
>
>, pull/387
>)
>like "_sd" and "_sd_alg" do)
>- *"..."* - Since this can never appear in the top level JSON object
>that represents the JWT Claims Set and appears exclusively as a property in
>a JSON array member that itself is an object, i.e. inside a Claim Value, it
>does not seem fit to be registered as a JSON Web Token Claim. However,
>lacking more details in the review instructions for designated experts I'm
>not finding a more solid ground to say no to it. That is other than this
>potentially far-fetching thought that since the registry entries are for
>"Claim Name"(s) and "..." can only appear inside "Claim Value" it seems
>like it needs no registration. Thoughts? Is my understanding of it never
>being on the top level JSON object correct?
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Wed, 2 Apr 2025 at 22:11, David Dong via RT <
> drafts-expert-review-comm...@iana.org> wrote:
>
>> Dear Mike Jones, Nat Sakimura, Filip Skokan (cc: Brian Campbell, oauth
>> WG),
>>
>> As the designated experts for the JSON Web Token Claims registry, can you
>> review the proposed registrations in
>> draft-ietf-oauth-selective-disclosure-jwt-17 for us? Please note Brian is a
>> co-author on this document.
>>
>> Please see:
>>
>>
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/
>>
>> The due date is April 23rd.
>>
>> If this is OK, when the IESG approves the document for publication, we'll
>> make the registration at:
>>
>> https://www.iana.org/assignments/jwt/
>>
>> We will assume that your response is a consensus response, unless you
>> tell us otherwise.
>>
>> Unless you ask us to wait for the other reviewer, we’ll act one week
>> after the first response we receive.
>>
>> With thanks,
>>
>> David Dong
>> IANA Services Sr. Specialist
>>
>

-- 
_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: draft-ietf-oauth-selective-disclosure-jwt embedding rules

[Chad Parry]

If it's OK, I have follow-ups below.

On 4/3/25 12:56, Daniel Fett wrote:
> Hi Chad,
>
> Thank you for your review of the specification! My comments below:
>
> Am 03.04.25 um 08:57 schrieb Chad Parry:
>  > The ellipsis name was introduced in version 5 of the specification,
>  > but the "_sd" name was retained. If an ellipsis is deemed more
>  > readable (section 4.2.4.2, and I agree it is), then why not use them
>  > instead of "_sd"? If the placeholder name needs to begin with an
>  > underscore, then presumably the existing ellipses usages are unsafe
>  > and need to be changed. In that case, "_..." would be fine too, as
>  > long as both object and array placeholders use a consistent name. In
>  > the payload above, I've used ellipses throughout.
>
> The "_sd" with the underscore was chosen (long before ...) to avoid
> potential conflicts with existing keys in the structure. The underscore
> has no special meaning, but the hope is that it makes it visually clear
> that this key has a special role.
>
> The "..." was chosen intentionally distinct from "_sd" to ensure that
> even when only parsing the structure without looking at the disclosures,
> the type of contents that can be expected in an object can be derived.

Makes sense. I would have tried to make the two keys similar since they
come from the same spec, but your argument is defensible. The current
format is a vast improvement over what I saw in the version 1 specification.

>  > In the specification, the value of the _sd property is always an array
>  > while the ... property is always a string. It would be more consistent
>  > if both could always be arrays. If brevity is desired, then a single
>  > digest can be treated as if it were an array of one. In my example,
>  > I've used arrays only when there are multiple digests.
>
> This creates polymorphism, which is usually not well-received by
> implementers, for good reasons.

Sure, that also makes sense.

>  > Claim birthdate Value:
>  > *  SHA-256 Hash: JL6Qz1obsng36vklAZGvir9NgVV2XsQa-1h4s7oHTrE
>  > *  Disclosure: WyJXOC1KSmpuU0ZPN1dlVUJ1UmZWQ1N3IiwgIjE5NDAtMDEtMDEiXQ
>  > *  Contents: ["W8-JJjnSFO7WeUBuRfVCSw", "1940-01-01"]
>  >
>  > Continuing in the same vein, the disclosed value could be a primitive
>  > instead of an object. The payload has non-selectively-disclosed a
>  > claim with the name "birthdate" but has not revealed whether it is a
>  > string or number, much less its value. This makes the substitution
>  > rules for property values the same as for array elements, which could
>  > already hide the type. It would also relax the constraints described
>  > in section 9.6, "Blinding Claim Names."
>
> Correct me if I'm wrong, but the same considerations would still apply.
> There would just be an additional option to always disclose the claim 
name.

>
>
>  >
>  > Array Entry:
>  > *  SHA-256 Hash: pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo
>  > *  Disclosure: WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0
>  > *  Contents: ["lklxF5jMYlGTPUovMNIvCA", "US"]
>  >
>  > Array entries in this example look exactly the same as the
>  > specification already describes. However, now they fit into a more
>  > robust pattern, where all disclosures consist of a salt and a value.
>  > Substitution rules would work the same for object properties
>  > (name/value pairs), array elements, and property values:
>  > 1. The disclosed value replaces whichever target object contained the
>  > ellipsis.
>  > 2. Except that if the target object contains other claims or digests,
>  > then the disclosed value must be an object type and its claims get
>  > merged into the target object instead of replacing it.
>
> As above, the price of this is that the structure itself is not
> self-explanatory anymore. In your example, without looking at the
> disclosures, I can't tell if nationalities is an array of strings or an
> array of objects.

I had thought that it was a feature to hide the shape of undisclosed
elements. Maybe I misunderstood the goals. Correct me if I'm wrong, but
in the current specification, it's already impossible to tell whether
"nationalities" is an array of strings or an array of objects (in
sections 4.2.6 and 5). IMHO, a self-explanatory structure is both
undesirable and unachievable.

As long as you support an embedding that has the format {"...":
""}, why restrict it to array elements? In section 7.1, step
3.2.2, the instructions say, "Find all array elements that are objects
with one key, that key being ... and referring to a string." It would be
simpler to explain and implement, "Find all objects with one key, that
key being ... and referring to a string."

You characterized this as "an additional option to always disclose the
claim name." That's true, but I don't think of it as adding a feature; I
think of it as removing an artificial restriction that doesn't appear
beneficial.

This change would be completely backward compatible for existing Issuers
and forward compatible for Verifier