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:
> 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 <kaduk@mit.edu> 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
> > Jwt-reg-review@ietf.org
> > 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._