I have read the draft and I think it brings a very valuable feature into the ACME ecosystem. It’s also a perfect fit in at least two of our projects, and I’d be happy to integrate it in our protocol flows.
The only concern I have with the current proposal is its reliance on WebAuthn’s as the sole encap format. The trouble is it only allows “background check”-style topologies [1], whilst we’d like to be able to support “passport” [2] as well. Therefore, I’d like to have WebAuthn as one of the supported formats, rather than the only supported format. (For a more generic encapsulation of attestation-related payloads you may want to take a look at [3].) Cheers, thanks t [1] https://www.ietf.org/archive/id/draft-ietf-rats-architecture-22.html#section-5.2 [2] https://www.ietf.org/archive/id/draft-ietf-rats-architecture-22.html#section-5.1 [3] https://datatracker.ietf.org/doc/draft-ftbs-rats-msg-wrap/ On 15/11/2022, 18:03, "Acme" <acme-boun...@ietf.org> wrote: This will be a three week call for adoption ending on 6 Dec. (because of holidays in the US). Please speak up either for or against adopting this draft. Thanks, Deb and Yoav. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
