Re: [jose] #16: URI identifying a specific key in a JWK set

["Manger, James H" <[e-mail]>]

> #16: URI identifying a specific key in a JWK set
>> http://trac.tools.ietf.org/wg/jose/trac/ticket/16

>  In order to evaluate this, we need to get a more detailed proposal

Below is a more detailed proposal. The basic idea is to make the JWK key set syntax a bit more sensible (keys named by their ids; instead of a "keys" element holding an array of keys); give key sets a media type; and define the fragment to be a JSON pointer [RFC 6901]. Then a URI can identify a specific key. A "jku" value can precisely indicate the key needed to process a JOSE message, eg "jku":"https://example.com/alice.keys#/k1".


>  1.  Syntax of the fragment

The fragment, if present, identifies a specific key in the JWK key set.

The fragment SHALL be a JSON Pointer [RFC 6901], pointing to the JSON object holding the specific key of interest within the set of keys.

The fragment SHALL be a "/" character followed by the key identifier ("kid" value) for the specific key.

[This implies the top-level structure of a JWK key set is changed to be a JSON object whose elements are individual keys. An element's name is the identifier of the key ("kid" value); an element's value is a single JWK object. One element (named "meta") is special: it is not a "kid" value, but a place to hold any metadata about the whole set of keys.

Example:
  {
    "k1" : {"kty":"EC","crv":"P-256","x":…,"y":…},
     2011-04-29" : {"kty":RSA","n":…,"e":"AQAB"}
  }
]


>  2.  dealing with duplicate values within a JWK structure

I'm not sure what this issue is. I suspect it is solved by storing keys as object elements as opposed to array items.

>  3.  Definition of a new media type - is this required or not - justify
>  either postion

The JWK spec should define a media type, such as application/keys+json.
Fragments are specific to a media type so a media type needs to be defined.

>  4.  Explain why the proposal is "better" than the current ability to
> have a url plus the kid in the message.

The whole concept of a URI is to be an identifier itself (not just when combined with a second field). Many, many systems and protocols that support URIs assume that the URI alone is sufficient to identify the item of interest.
It simplifies APIs and protocols: just pass 1 value.

>  5.  Discuss what happens if the fragment is not present on the url

The specs should be written so that if there is no fragment but there is only 1 key in the identified JWK key set, then things still work.

I suggest saying a *creator* of a "jku" URI value (to identify the specific key required to process a JOSE message) MUST include a fragment to identify a single key. When a key set has only 1 key, a *receiver* MUST accept a "jku" URI as an identifier of that 1 key even if the URI has no fragment.

> or if the fragment is not findable in the resultant document.

Then the URI identifies a key that is not present so an error results (similar to getting a 404 Not Found for the whole key set).

>  If the fragment
>  is going to be manditory does them mean that we should be doing a new
>  scheme instead as fragments cannot be required under the current URL
>  syntax defintions (or at least that is my reading).

Definitely no new URI scheme.
A URI without a fragment is still a valid URI. That doesn't stop us saying a "jku" URI value MUST contain a fragment.

>  Please flesh out your proposal more so that it can be fully evaluated.

I hope this email has fleshed out a proposal sufficiently.

--
James Manger