[stir] Re: [Acme] Call for adoption for draft-wendt-acme-authority-token-jwtclaimcon

[Chris Wendt <[e-mail]>]

+ STIR WG

Hi Mike,  

I have cross posted this cc to the STIR WG list.  To be quite honest, many of the ultimate implementers are not super active in IETF, but there is some, so hopefully we get some positive indicators.  I will and already have promoted this spec and other related dependent specs on the use of ACME and Authority tokens in STIR in an industry interoperability event we hold periodically, but again, those participants are not active in IETF mailing lists (as far as I’m aware).  Telecom specs generally start in IETF and progress to ATIS in the US and others 3GPP etc.  So, while I would love to be optimistic we get immediate implementations, I’m afraid we may not hear overwhelming feedback.  Just being realistic.

The good news is as I’ve discussed in my presentations, Authority tokens and TNAuthList Authority tokens is already widely adopted and implemented and in wide use with ACME implementations that issue STIR Certificates.  JWTClaimConstraints follows a very similar pattern but also part of an emerging use of Rich Call Data and other PASSporT Claims that may evolve in the future so this is sort of a foundational spec that will help enable these things in the future, so there is pretty clear needs and I think there was a few people that came to the microphone to state their support that this is needed.

I would encourage those that stated support to state it again on the list if possible, but I think this is a pretty simple win to have this spec formalized and available for the STIR related Call Authentication and Robocalling work going on in the world.

Thanks!

-Chris


> On Sep 26, 2025, at 7:04 PM, Mike Ounsworth <[e-mail]> wrote:
> 
> Hi Chris,
> 
> Oh right. This was the draft with the STIR tie-in. I think this proves the point why people need to reply to the call-for-adoption thread, and not rely on my memory. (remember also that I was only at half the last f2f due to scheduling conflicts, so I don't think I was actually there for your presentation). I see some discussion in the 123 minutes, but it's pretty light on "consensus for adoption".
> https://datatracker.ietf.org/doc/minutes-123-acme/
> 
> Ok. I am willing to extend the call for adoption period. Can you please write up a description of the STIR tie-in, and post that to this thread?
> Since you are requesting that this document be Standards Track (rather than Informational), I will be most interested in people who are committed to implement this draft and do inter-op testing.
> 
> On Fri, 26 Sept 2025 at 17:47, Chris Wendt <[e-mail] <mailto:[e-mail]>> wrote:
>> Hi Mike,
>> 
>> Just a reminder that I do recall at least a few folks that spoke up in the f2f meeting giving support that were visiting from the Stir WG that would be the primary audience and may not be on the ACME list. Would that count towards consensus, I would hope?
>> 
>> -Chris
>> 
>>> On Sep 26, 2025, at 11:08 AM, Mike Ounsworth <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> 
>>> Hello ACME!
>>> 
>>> The Call for Adoption for draft-wendt-acme-authority-token-jwtclaimcon closed on 2025-09-22. Despite MCR's positive review, one comment does not constitute working group consensus. I am going to leave this document in datatracker in the state Candidate For Adoption. I encourage the authors to present at the ACME session it IETF 124 with the goal of drumming up more interest in this draft, particularly from implementers.
>>> 
>>> On Wed, 10 Sept 2025 at 16:14, Michael Richardson <[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>> I read acme-authority-token-jwtclaimcon-03.
>>>> I was led into reviewing RFC8225, and RFC8226.
>>>> The document seems well formed and very complete, and I think it could
>>>> rapidly go to WGLC.
>>>> 
>>>> I found the explanation around token-authority in section 4 a bit hard to
>>>> understand.  I was in "smile and nod" mode.  I think those who know will
>>>> know, but reviewers might balk.  I'm rather unclear what the ACME client will
>>>> do with this.   I thought I understood RFC9447 well enough already, but
>>>> clearly I don't.
>>>> 
>>>> More consistent indenting of the JSON/JWT would be appreciated, such as the
>>>> POST in section 4.
>>>> 
>>>> I think that the "url" attribute in the Authorization object is the identical
>>>> prV_B... as from RFC8555.  That's not wrong, it's just an example...., but I
>>>> worry that someone will think they need to be the same, and I think that in
>>>> real life they need to be different.  So make up a new random URL.
>>>> 
>>>> I hadn't realized that these STIR PKIX certificates had JWT in an extension!
>>>> Is this new?  Is this why this document exists?
>>>> 
>>>> Is the account id mentioned in section 5.2 related to the ACME Account?
>>>> I think not.
>>>> 
>>>> Should section 5.2 mention returning the response to the ACME server at the
>>>> challenge URL?
>>>> 
>>>> }5.5.  ACME Challenges requiring multiple Authority Tokens
>>>> }
>>>> }   The ACME new-order request may include multiple identifiers, each of
>>>> }   which is authorized separately.  With the introduction of this
>>>> }   specification, for STIR certificates [RFC8226] two identifier types
>>>> }   are authorized using Authority Tokens:
>>>> 
>>>> I read the document to understand how this document was dealing/documenting
>>>> multiple identities, as ACME-RATS needs/wants to do the same.
>>>> 
>>>> Please include the DER for the examples in section 5.5.1.1 and 5.5.1.2.
>>>>              UTF8String '"nam": "James Bond"'
>>>> 
>>>> The use of ' and " quotes here was confusing to me at first scan.
>>>> I think that inner parts are actually JSON?
>>>> 
>>>> Section 5.5.2 has "sti-ca.com <http://sti-ca.com/>" rathere than example.com <http://example.com/>.
>>>> 
>>>> Who will be implementing this?
>>>> 
>>>> --
>>>> Michael Richardson <[e-mail] <mailto:[e-mail]>>   . o O ( IPv6 IøT consulting )
>>>>            Sandelman Software Works Inc, Ottawa and Worldwide
>>> _______________________________________________
>>> Acme mailing list -- [e-mail] <mailto:[e-mail]>
>>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> _______________________________________________
> Acme mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]