I would summarize my reaction to this document as "I can live with it, but
it makes me really sad that we didn't do the stupid simple obvious thing."
The computation of the hash input is technically workable, but
unnecessarily complex. Rather than building a simple string based on the
components (say, ), it basically requires the implementor to make a custom
JSON serializer to ensure that the fields are serialized in the right order.
Using Javascript as an example, instead of just doing a simple string
construction:
tp_input = [jwk.e, jwk.kty, jwk.n].join("|")
... instead, I construct and fill in a template:
tp_input = '{"e":"JWK_E","kty":"JWK_KTY","n":"JWK_N"}'
.replace("JWK_E", jwk.e)
.replace("JWK_KTY", jwk.kty)
.replace("JWK_N", jwk.n)
Requiring a lot of manual coding like this seems to invite interop issues.
The remainder of the text looks fine to me, though.
--Richard
On Thu, Jan 22, 2015 at 8:56 PM, Jim Schaad <[email protected]> wrote:
> This starts a two week last call on draft-ietf-jose-jwk-thumbprint. Last
> call will end on February 2, 2015.
>
>
>
> Due to the general lack of activity on the list. General silence will be
> considered as a vote to park the document and either have it done via the
> ISE or with an AD shepherd rather than having group consensus.
>
>
>
>
>
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
>
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
