It is the first case. JOSE libraries are typically using the built in JSON parsers in their environments at the moment. Not surprisingly as the parsers are built in to most languages now. It is those that don't reject duplicate members, not the JOSE libraries as the parser makes all but one of the duplicates disappear in most if not all cases.
John B. On Sep 16, 2014, at 5:07 PM, Stephen Kent <[email protected]> wrote: > Mike, >> ... >> >> JWK objects are already used in production to distribute public keys. For >> instance, the keys for Salesforce’s identity services are in JWK format at >> https://login.salesforce.com/id/keys. (Note that I’m not saying that just >> because the current specs are in use, that no changes are possible.) >> if not that, what is the point of this comment? >> >> The point of the comment was simply to answer your question “What is the >> existing software to which you and Tim refer…?” > And I have not yet received an answer to that question, in terms I can > understand. > > Let me try again. > > What is the impediment to requiring a receiver of a JWK object to reject the > object if > it contains more than one instance of a key? > > Is it a limitation of a parser that are completely independent of the JOSE > work that defines > the JWK objects, or is it the result of how folks have written code to parse > such objects? > > If the answer is the first clause, then I understand the reluctance to impose > that requirement. > > If the answer is the latter, then this is an argument based on early > implementation > of an IETF spec, and that is not an good reason to accommodate such > sloppiness. > > Steve > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
