IMO one of the major problems with JOSE is that the algorithm to be used for verification is part of the object being verified and is generally not part of the

IMO one of the major problems with JOSE is that the algorithm to be used for verification is part of the object being verified and is generally not part of the verification API or the verification key. This results in the alg "none" attack and no shortage of potential downgrade attacks. After quickly skimming these drafts, I can’t tell whether it’s fixed. Certainly a lot of algorithm names are sprinkled around the encoded objects, but I didn’t spot a description of what a public key is. I am moderately concerned by statements like: 6.3.2. Issuer Setup To use the MAC algorithm the issuer must have a stable public key pair to perform signing. To start the issuance process, a single 32-byte random Shared Secret must first be generated. This value will be shared privately to the holder as part of the issuer's JWP proof value Few if any cryptosystems are intended to be secure if the private key is used in the wrong algorithm. This paragraph reads like one party should, as part of the API used by the application, one party sends 32 bytes, char[32]-style, to another. I don’t think any new design should work like this. New designs should fail hard when misused or when parties disagree as to what protocol variant they’re speaking. Is there something in here to make the new standard clearly immune to algorithm confusion attacks?