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

[Brian Campbell <[e-mail]>]

[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 <[e-mail]> wrote:

> On Thu, Nov 01, 2018 at 01:56:42PM -0600, Brian Campbell wrote:
> > 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
>
> 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)
>
> > 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
>
> 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
>
> > On Thu, Nov 1, 2018 at 11:06 AM Benjamin Kaduk <[e-mail]> wrote:
> >
> > > 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
> > >
> > > _______________________________________________
> > > Jwt-reg-review mailing list
> > > [e-mail]
> > > 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._
>

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