-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
paramaters x5c and x5t#S256 and GNAP key formats #222
Comments
Currently in section 7.1, the non-normative example shows a single key presented in multiple formats (PEM and JWK), but " If a key is sent in multiple formats, all the key format values MUST be equivalent" could be interpreted in different ways. Probably to be clarified. So I guess there's different things to consider:
I also agree there's more importance in making key rotation easy than is supporting multiple formats, at least in the core. |
I decided originally to not just use JWK in the XYZ drafts for a few reasons:
Now don't get me wrong, I love JWK and having a structured format to carry bare public keys is an amazing innovation -- but we can't assume that's what everyone in the world is going to use for this very fundamental part of the negotiation process. With all of that in mind I'm still in favor of having the certificate separate so that we can do:
|
+1
|
Those reasons are valid, although pretty much everything could be dealt with through a proper extension mechanism (which I think is important). Fetchable keys could work differently though, and so having that possibility in the core would make sense. |
@fimbault I haven't checked in the HTTP Sig changes that will allow JWA algorithms yet, but I'm working on it. :) This would be independent of the key format, though. |
Can't depend on JWK only, we need to keep the system open to a variety of formats (e.g. certs, etc.). |
@fimbault, @jricher, from my (very pragmatic) perspective, I'm more than fine with the support of a variety of different formats. Although, JWKs are still being too flexible. Hence, I suggest specifying if it's allowed to use and/or mix parameters
which makes perfect sense to me. Also, I still suggest changing the language used to describe what JWK is to
this is the definition provided by RFC 7517. |
The |
Closing as discussed last week on the mailing list |
RFC 7517 (JSON Web Key) defines a JWK as
The current draft does it as
that could be a minor editorial change. Although, at the same time, RFC 7517 defines parameters such as
x5c
andx5t#S256
which, for the most part, intersect withcert
andcert#S256
key formats introduced in section "Key Formats". The question I have is what are the reasons to define these formats if the same goals are achievable with JWKs only?Thus, we would use something like
instead of
That would allows to omit
cert
andcert#S256
and express the same (single) key in multiple formats. Furthermore, this could allow to have a bit more simplified approach for #105.The text was updated successfully, but these errors were encountered: