On 20 Jan 2023, at 18:47, Brian Campbell <bcampbell=40pingidentity....@dmarc.ietf.org> wrote:
Hi Mark,
Thanks for the review and feedback. I am aware of HTTP Structured Fields and certainly see value in it - even using it in some other work in which I'm involved. However, I'm unsure of its fit or utility for this draft. With that said, I've tried to reply more specifically to your comments inline below.
A few things caught my eye in this document:
- Section 4.1 defines the DPoP header field as a JWT, which (as I understand it) is a base64-encoded string. If that's the case, I'd recommend making it a Structured Field Item (see RFC8941 s 3.3) with a fixed type of Byte Sequence (s 3.3.5). That will require changing the syntax to add a prefix and suffix of ":".
As Justin pointed out, a JWT is three Base64url encoded segments delimited by the `.` period character, which means it can't be a SF Byte Sequence. As DW pointed out, a JWT just happens to always start with a letter because the first segment is always encoded JSON, so will always start with 'ey'. So the DPoP header field value does just happen to fit the SF Token syntax, But the SF Token syntax does very little regarding the validity of the JWT.
Being quite pedantic here, the JWT header is allowed to have preceding whitespace so it might not always start ‘eY’. That said, to be non-alphabetic the first 6 bits would need to be > 52, which in particular means the msb of the first byte would have to be set - implying a multibyte UTF-8 sequence. JSON only allows space, tab, newline, or carriage return before the opening brace so I think we’re still good.
(I don’t think I’ve ever seen a JWT in the wild that didn’t start eY).
— Neil |
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
