RE: [Bug 26123] New: Key ID definition should be aligned with JWK kid definition

If Mark agrees with you, at a minimum, these kinds of usage assumptions (such as uniqueness, being a hardware abstraction, etc.) motivating the choice of data structure should be described in the spec.

If he does agree that it needs to remain an encoded representation of an octet sequence, I’ll file a separate bug, which is that it should be base64url encoded, rather than base64 encoded, since WebCrypto implementations will already be using base64url encoding in other contexts but aren’t elsewhere using base64 encoding.

                                                                -- Mike

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Tuesday, June 17, 2014 3:55 PM
To: Mike Jones
Cc: public-webcrypto@w3.org
Subject: RE: [Bug 26123] New: Key ID definition should be aligned with JWK kid definition


On Jun 17, 2014 3:38 PM, "Mike Jones" <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:
>
> To the extent that the WebCrypto specs use two values that are described as being key identifiers, the onus should be on the working group to make the case why they need to be incompatible with one other.

Respectfully, I cannot agree with you at all on this point.

The Web Crypto API is not a JOSE API. This has been repeatedly reaffirmed. The removal of aliases further underscores this - they are not meant to be 1:1 mappings.

Just because two things look the same, on an abstract level, does not for a second mean they have the same purpose or requirements.

>  No, they aren’t the same thing, but I can easily picture use cases where it would be convenient to use the same Key ID value in both places.
>

I seriously doubt this in practice, given the use cases Mark has laid out, but sure, for situations in this hypothetical, one can imagine.

>
>
> The problem is that while one is a string, one is a base64 encoded representation of an octet sequence with a bounded size.  (They’re reusable in one direction, but not the other.)  Is there some good reason why both can’t just be strings?
>

Because they identify different things and for different purposes.

The jwk kid is useful for JOSE systems, and in particular JWE/JWS/JWT, and relate to JOSE-using protocols.

The NamedKey API is a UA/Hardware abstraction, meant not for JWKs but for software developers interacting with the API.

The two are apples and oranges, orthogonal in both purpose and use.

This is the same discussion we have had on Algorithm Names - Web Crypto is designed for *API* and programmatic usage, JOSE is designed for serialization.

Mark had favored a particular hardware implementation/design space, as covered in the F2F. NamedKey IDs are globally unique (eg: no two UAs will have the same NamedKey, or at least, that's the plan), whereas JWK kids are symbolic identifiers that are tied to a specific context and protocol message exchange.

NamedKey IDs are generally assigned out of band by a service provider, and identify user as much as user agent, whereas JWK key IDs are generally symbolic and lack such context (eg: they contain a date, or a friendly name, or a name like 'Mike's encryption key')

Different purposes. Different definitions.

Further, the use of KID is not at all coupled to requiring named key discovery. JOSE applications would far more likely use WebCrypto CryptoKeys, and store things like kid as supplemental data in their long term storage (eg: as the key identifier within IDB).

>
>
>                                                                 -- Mike
>
>
>
> From: Ryan Sleevi [mailto:sleevi@google.com<mailto:sleevi@google.com>]
> Sent: Tuesday, June 17, 2014 3:28 PM
> To: bugzilla@jessica.w3.org<mailto:bugzilla@jessica.w3.org>
> Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>; Mike Jones
> Subject: Re: [Bug 26123] New: Key ID definition should be aligned with JWK kid definition
>
>
>
> Mike,
>
> Can you explain why they should be aligned?
>
> Named Key and kid have no relationship. Deserializing a JWK with a kid does not yield a NamedKey, and serializing a NamedKey doesn't result in a JWK with kid set.
>
> Further, their use of id concepts are for separate purposes.
>
> While I have little personal interest in NamedKey, this seems like an unnecessary/unwarranted change.
>
> If kid is going to be handled, you'd do it at the application layer - named key or not - and it would not work with wrap/unwrap.
>
> Note that CryptoKey (not NamedKey) are equally not meant to be 1:1 relationships with JWK. They are independent.