Subject: Re: [Jwt-reg-review] JWT claim registration review request : draft-ietf-stir-passport-shaken

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 1 Nov 2018 12:06:18 -0500

The requested registrations include:

"attest", "Attestation level as defined in SHAKEN framework"
"origid", "Originating Identifier as defined in SHAKEN"

It seems unlikely to me that SHAKEN is the only group that will ever want
an attestation level, and probably not the only one for an originating
identifier either (though I did not read the draft yet and am going just by
the name).  What are the normal considerations that the Experts are
applying about generic names and whether additional references could be
added for the claim indicating its usage in alternative contexts?

-Ben

---

From: Brian Campbell <[email-masked]>
Date: Thu, 1 Nov 2018 13:56:42 -0600

That's a good question, Ben.

I don't think we've necessarily established normal in that regard and have
maybe been somewhat inconsistent about it. In practice, registration is
really the only option for a spec that wants to have a short claim name
while also having some protection against name collision - even for things
that are application specific and aren't wildly applicable. As such, I
support registration of claim names even when they are defined in or for an
application specific context. However, I'd prefer to see such names not
being generic but rather to have some indicator of their specificity. These
claims from draft-ietf-stir-passport-shaken do seem to fall into that
category and I'd be happier if they were "shkn-att" and "shkn-ogid" or
something along those lines. But like I said, we've been been rather
inconsistent about that kind of thing historically as you can see with the
current registrations https://www.iana.org/assignments/jwt/jwt.xhtml and so
I'm somewhat hesitant to rock the boat by pushing back on these kinds of
registration requests now. Especially because it's typically a PITA for the
WG or whoever is making the request to make changes to their spec by the
time they've gotten to the point of making a JWT claim registration
request. And the downside is only that a generic looking name gets taken
for a more specific context. There's nothing in the registry or
registration process or guidelines that would allow for or account for
usage in alternative contexts. So registration is effectively all or
nothing.

I'm not sure that really answers your question. But that's the best answer
I've got.

I'm also not sure where that leaves us with this particular request.

On Thu, Nov 1, 2018 at 11:06 AM Benjamin Kaduk <[email-masked]> wrote:

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

-- 
_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: Benjamin Kaduk <[email-masked]>
Date: Thu, 1 Nov 2018 18:29:14 -0500

> application specific context. However, I'd prefer to see such names not

Yup, I'd also prefer registrations, even generic-sounding ones, over
unregistered usage.

> being generic but rather to have some indicator of their specificity. These

(and that, too)

> registration requests now. Especially because it's typically a PITA for the

I appreciate that there are many, sometimes competing, factors that you
must consider as an Expert.  (And to be clear: you are the Experts, and I
am deferring to your expertise here.)

> usage in alternative contexts. So registration is effectively all or

I'm not sure if I'll be able to attend an OAuth session in Bangkok, but
perhaps the general topic of claim reuse in disjoint settings could be
raised.  (In that a potential solution for future requests of this type
would be to allow them but also allow for the claim name to be reused
elsewhere with different semantics.  Emphasis on "potential".)

> I'm not sure that really answers your question. But that's the best answer

I am happy to have it :)

> I'm also not sure where that leaves us with this particular request.

There is a line of "likely to be of general applicability or whether it is
useful only for a single application" in the guidance to the experts, but
that doesn't actually say much about whether one or the other are grounds
to push back on or refuse a registration.  That said, I think it's
appropriate to have a culture where the experts are comfortable pushing
back on requests, when the experts are uncomfortable with the requests in
question.

-Ben

---

From: Mike Jones <[email-masked]>
Date: Mon, 5 Nov 2018 02:59:30 +0000

We've already established the precedent that we're willing to register generic-sounding claim names for applications that we believe will have broad deployment.  For instance, we registered "orig" and "dest" in https://tools.ietf.org/html/rfc8225#section-11.2.  Therefore, I think it makes sense to also register "attest" and "origid" as specified in https://tools.ietf.org/html/draft-ietf-stir-passport-shaken-04#section-10.1 - also for use in the PASSporT context.

As a designated expert, I approve of these registrations.

				-- Mike

-----Original Message-----
From: Jwt-reg-review <[email-masked]> On Behalf Of Benjamin Kaduk
Sent: Friday, November 2, 2018 6:29 AM
To: Brian Campbell <[email-masked]>
Cc: [email-masked]
Subject: Re: [Jwt-reg-review] JWT claim registration review request : draft-ietf-stir-passport-shaken

On Thu, Nov 01, 2018 at 01:56:42PM -0600, Brian Campbell wrote:
> I don't think we've necessarily established normal in that regard and 
> have maybe been somewhat inconsistent about it. In practice, 
> registration is really the only option for a spec that wants to have a 
> short claim name while also having some protection against name 
> collision - even for things that are application specific and aren't 
> wildly applicable. As such, I support registration of claim names even 
> when they are defined in or for an application specific context. 
> However, I'd prefer to see such names not

Yup, I'd also prefer registrations, even generic-sounding ones, over unregistered usage.

(and that, too)

> inconsistent about that kind of thing historically as you can see with 
> the current registrations 
> https://www.iana.org/assignments/jwt/jwt.xhtml and so I'm somewhat 
> hesitant to rock the boat by pushing back on these kinds of 

I appreciate that there are many, sometimes competing, factors that you must consider as an Expert.  (And to be clear: you are the Experts, and I am deferring to your expertise here.)

> WG or whoever is making the request to make changes to their spec by 
> the time they've gotten to the point of making a JWT claim 
> registration request. And the downside is only that a generic looking 
> name gets taken for a more specific context. There's nothing in the 
> registry or registration process or guidelines that would allow for or 
> account for usage in alternative contexts. So registration is 
> effectively all or nothing.

I'm not sure if I'll be able to attend an OAuth session in Bangkok, but perhaps the general topic of claim reuse in disjoint settings could be raised.  (In that a potential solution for future requests of this type would be to allow them but also allow for the claim name to be reused elsewhere with different semantics.  Emphasis on "potential".)

> I'm not sure that really answers your question. But that's the best 
> answer I've got.

I am happy to have it :)

> I'm also not sure where that leaves us with this particular request.

There is a line of "likely to be of general applicability or whether it is useful only for a single application" in the guidance to the experts, but that doesn't actually say much about whether one or the other are grounds to push back on or refuse a registration.  That said, I think it's appropriate to have a culture where the experts are comfortable pushing back on requests, when the experts are uncomfortable with the requests in question.

-Ben

> > It seems unlikely to me that SHAKEN is the only group that will ever 
> > want an attestation level, and probably not the only one for an 
> > originating identifier either (though I did not read the draft yet 
> > and am going just by the name).  What are the normal considerations 
> > that the Experts are applying about generic names and whether 
> > additional references could be added for the claim indicating its usage in alternative contexts?
> >
> > -Ben
> >
> _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: Benjamin Kaduk <[email-masked]>
Date: Sun, 4 Nov 2018 21:14:13 -0600

On Mon, Nov 05, 2018 at 02:59:30AM +0000, Mike Jones wrote:
> We've already established the precedent that we're willing to register
> generic-sounding claim names for applications that we believe will have
> broad deployment.  For instance, we registered "orig" and "dest" in

Okay, thanks for clarifying the precedent for me!

-Ben

> https://tools.ietf.org/html/rfc8225#section-11.2.  Therefore, I think it
> makes sense to also register "attest" and "origid" as specified in
> https://tools.ietf.org/html/draft-ietf-stir-passport-shaken-04#section-10.1
> - also for use in the PASSporT context.
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 5 Nov 2018 14:35:27 +0700

[Noticed the recipients of the original message
https://mailarchive.ietf.org/arch/msg/jwt-reg-review/mkGyvI2ZO20EFCPmObIlhl5UuNE
had fallen off the distribution so added them back]

There are two OAuth sessions in Bangkok, however, the agenda already looks
rather full. The idea of somehow allowing for registered claim reuse in
disjoint settings sounds interesting. But even as a so called Designated
Expert I don't think I'm expert enough or smart enough to gauge whether or
not a context of use is truly disjoint and will continue to be disjoint
into the future.

Indeed I've read (and reread) RFC7519's guidance but don't find it
particularly helpful in guiding any decision making in this kind of
situation. I also think it'd be appropriate to have a culture where the
experts are comfortable pushing back on requests. And I have done that on
occasion previously for requests that just didn't make sense at all. But in
this case it's not clear that there really should be push back given
general historical precedent and the situation of having somewhat generic
names for specific usage being 'not that bad'.

I do think it would be useful if RFC7519 had some guidance or suggestions
to would-be registrants about choosing claim names. But I don't know that
from a practical perspective anything can be done in that regard at this
point.

On Thu, Nov 1, 2018 at 5:29 PM Benjamin Kaduk <[email-masked]> wrote:

> have
> the
> answer
> want
> privileged

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 5 Nov 2018 06:28:06 -0600

> names for specific usage being 'not that bad'.

Agreed, it is really "not that bad".

> from a practical perspective anything can be done in that regard at this

The only thing I can think of would be to publish a new document that adds
a Note to the registry including (a link to, or) guidance on choosing claim
names.

-Ben