Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31

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 <kent@bbn.com> 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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31

Attachment: smime.p7s