Subject: Re: [Jwt-reg-review] Request to register claim: sig_val_claims

From: Mike Jones <[email-masked]>
Date: Thu, 13 Jan 2022 02:44:03 +0000

I approve of the registration of this claim.

				-- Mike

-----Original Message-----
From: Jwt-reg-review <[email-masked]> On Behalf Of Stefan Santesson
Sent: Friday, September 3, 2021 8:33 AM
To: [email-masked]
Cc: Russ Housley <[email-masked]>
Subject: [EXTERNAL] [Jwt-reg-review] Request to register claim: sig_val_claims

Hi,

The draft https://datatracker.ietf.org/doc/draft-santesson-svt/ is being requested for publication as individual submission

This draft includes the request to register the claim name "sig_val_claims" as follows:

6.1.  Claim Names Registration

   This section registers the "sig_val_claims" claim name in the IANA
   "JSON Web Token Claims" registry established by Section 10.1 in
   [RFC7519].

6.1.1.  Registry Contents

   *  Claim Name: "sig_val_claims"
   *  Claim Description: Signature Validation Token Claims
   *  Change Controller: IESG
   *  Specification Document(s): Section 3.2.3 of {this document}

The draft specifies a Token having the form of a JWT which includes this defined claim.

The rationale for this claim is described in the referenced document.

The solution is deployed is real services and it is considered for national government usage which is the main reason to publish the specification as an informational RFC.

/Stefan Santesson

_______________________________________________
Jwt-reg-review mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jwt-reg-review

---

From: Brian Campbell <[email-masked]>
Date: Fri, 14 Jan 2022 14:24:24 -0700

Honestly, I can't really wrap my head around this kind of signature
indirection so I'll just say that I'm okay with the registration of the
claim name "sig_val_claims".

Because the document is defining this SVT, which is one particular kind of
JWT, I wonder if it'd be worthwhile to consider explicitly typing it, as
recommended in https://datatracker.ietf.org/doc/html/rfc8725#section-3.11,
with something like a "typ":"svt+jwt" header rather than the general and
kinda meaningless "typ":"jwt"?

On Wed, Jan 12, 2022 at 7:44 PM Mike Jones <Michael.Jones=
[email-masked]> wrote:

> The draft https://datatracker.ietf.org/doc/draft-santesson-svt/ is being
> requested for publication as individual submission
>
> The solution is deployed is real services and it is considered for
> national government usage which is the main reason to publish the
> specification as an informational RFC.
>
>
>
> /Stefan Santesson
>
>

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

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 15 Jan 2022 15:01:19 +0100

Brian,

Thank you for the suggestion. Our current implementations use the jwt
type declaration as this technically is a JWT. This also works well with
standard tools as long as we can define the claim as requested here.

Having a specific type like svt+jwt might be a good idea. I'm not sure
exactly what implications that brings to our current implementations. If
we register a "svt+jwt" type, could it's user be optional? How would we
go ahead and do the registration of this type?

/Stefan

Den 2022-01-14 kl. 22:24, skrev Brian Campbell:
> indirection so I'll just say that I'm okay with the registration of
> the claim name "sig_val_claims".
>
> Because the document is defining this SVT, which is one particular
> kind of JWT, I wonder if it'd be worthwhile to consider explicitly
> typing it, as recommended in
> https://datatracker.ietf.org/doc/html/rfc8725#section-3.11, with
> something like a "typ":"svt+jwt" header rather than the general and
> On Wed, Jan 12, 2022 at 7:44 PM Mike Jones
> <Michael.Jones=[email-masked]> wrote:
>
>     The draft https://datatracker.ietf.org/doc/draft-santesson-svt/ is
>     being requested for publication as individual submission
>
> /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./

---

From: Brian Campbell <[email-masked]>
Date: Sun, 16 Jan 2022 06:58:54 -0700

It'd be a media type registration - the text in 3.11.  Use Explicit Typing
<https://datatracker.ietf.org/doc/html/rfc8725#section-3.11> of the JWT BCP
explains it a bit more and references RFC8417 that has
https://datatracker.ietf.org/doc/html/rfc8417#section-7.3 as an example of
such a registration request. Looking for +jwt in the registry
https://www.iana.org/assignments/media-types/media-types.xhtml will turn up
a few others too.

I believe you could define its use in SVT however makes sense given the
constraints you have with existing implementations or whatever. I.e. typ
has to be either jwt or svt+jwt. I suppose that waters it down a bit but is
possible.

Or maybe it's not worth doing at this point. It was just something that
jumped out at me when trying to do a quick review of the draft.

On Sat, Jan 15, 2022 at 7:01 AM Stefan Santesson <[email-masked]> wrote:

> Brian,
>
> Thank you for the suggestion. Our current implementations use the jwt type
> declaration as this technically is a JWT. This also works well with
> exactly what implications that brings to our current implementations. If we
> register a "svt+jwt" type, could it's user be optional? How would we go
> ahead and do the registration of this type?
>
> /Stefan
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> 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.*
>
>

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 16 Jan 2022 21:17:05 +0100

Thank you!

The suggestion is tempting. We will discuss how to progress on this
matter if it is worth doing.

However, if I understand this right, this does not affect registration
of the sig_cal_calims claim identifier right?

/Stefan

Den 2022-01-16 kl. 14:58, skrev Brian Campbell:
> It'd be a media type registration - the text in 3.11.  Use Explicit
> Typing <https://datatracker.ietf.org/doc/html/rfc8725#section-3.11> of
> the JWT BCP explains it a bit more and references RFC8417 that has
> https://datatracker.ietf.org/doc/html/rfc8417#section-7.3 as an
> example of such a registration request. Looking for +jwt in the
> registry
> https://www.iana.org/assignments/media-types/media-types.xhtml will
> turn up a few others too.
>
> I believe you could define its use in SVT however makes sense given
> the constraints you have with existing implementations or whatever.
> I.e. typ has to be either jwt or svt+jwt. I suppose that waters it
> down a bit but is possible.
>
> Or maybe it's not worth doing at this point. It was just something
> that jumped out at me when trying to do a quick review of the draft.
>
>     Thank you for the suggestion. Our current implementations use the
>     jwt type declaration as this technically is a JWT. This also works
>     well with standard tools as long as we can define the claim as
>     requested here.
>
>     Having a specific type like svt+jwt might be a good idea. I'm not
>     sure exactly what implications that brings to our current
>     implementations. If we register a "svt+jwt" type, could it's user
>     be optional? How would we go ahead and do the registration of this
>     type?
>
>     /Stefan
>
>
>>     Honestly, I can't really wrap my head around this kind of
>>     signature indirection so I'll just say that I'm okay with the
>>     registration of the claim name "sig_val_claims".
>>
>>     Because the document is defining this SVT, which is one
>>     particular kind of JWT, I wonder if it'd be worthwhile to
>>     consider explicitly typing it, as recommended in
>>     something like a "typ":"svt+jwt" header rather than the general
>>     and kinda meaningless "typ":"jwt"?
>>      
>>
>>         The draft
>>         https://datatracker.ietf.org/doc/draft-santesson-svt/ is
>>         The solution is deployed is real services and it is
>>         considered for national government usage which is the main
>>         reason to publish the specification as an informational RFC.
>>
>>
>>
>>         /Stefan Santesson
>>
>>
>>     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./ 
>
>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 18 Jan 2022 06:53:37 -0700

Yeah, correct, the typ suggestion does not affect registration of the
sig_cal_calims claim.

On Sun, Jan 16, 2022 at 1:17 PM Stefan Santesson <[email-masked]> wrote:

> Thank you!
>
> The suggestion is tempting. We will discuss how to progress on this matter
> if it is worth doing.
>
> However, if I understand this right, this does not affect registration of
> the sig_cal_calims claim identifier right?
>
> /Stefan
>
>
>
> <https://datatracker.ietf.org/doc/html/rfc8725#section-3.11> of the JWT
> BCP explains it a bit more and references RFC8417 that has
> https://datatracker.ietf.org/doc/html/rfc8417#section-7.3 as an example
> of such a registration request. Looking for +jwt in the registry
> https://www.iana.org/assignments/media-types/media-types.xhtml will turn
> up a few others too.
>
>> Because the document is defining this SVT, which is one particular kind
>> of JWT, I wonder if it'd be worthwhile to consider explicitly typing it, as