Add IANA registration for JWS types #533
Conversation
✅ Deploy Preview for gnap-core-protocol-editors-draft ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
draft-ietf-gnap-core-protocol.md
Outdated
| To indicate that the content is a GNAP message to be bound with a detached JWS mechanism: | ||
|
|
||
| * Type name: application | ||
| * Subtype name: gnap-binding+jwsd |
There was a problem hiding this comment.
you don't have examples using this anymore, will it be clear how it is used?
There was a problem hiding this comment.
There was a problem hiding this comment.
| * Subtype name: gnap-binding+jwsd | |
| * Subtype name: gnap-binding+jws |
There was a problem hiding this comment.
jwsd is unnecessary and should be deleted. Per https://www.rfc-editor.org/rfc/rfc7515.html#appendix-F, you can tell whether the payload is detached by whether the payload field is empty.
draft-ietf-gnap-core-protocol.md
Outdated
|
|
||
| To indicate the content is a compact form JWS as defined by {{RFC7515}} with detached payload: | ||
|
|
||
| * Name: Detached JWS |
There was a problem hiding this comment.
jwsd is unnecessary and should be deleted. Per https://www.rfc-editor.org/rfc/rfc7515.html#appendix-F, you can tell whether the payload is detached or not by whether the payload field is empty or not.
draft-ietf-gnap-core-protocol.md
Outdated
| * Name: JWS | ||
| * +suffix: +jws | ||
| * References: {{&SELF}} | ||
| * Encoding considerations: binary; JWS values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') characters. |
There was a problem hiding this comment.
| * Encoding considerations: binary; JWS values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') characters. | |
| * Encoding considerations: binary; JWS values using the compact serialization are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') characters. |
draft-ietf-gnap-core-protocol.md
Outdated
| To indicate that the content is a GNAP message to be bound with a detached JWS mechanism: | ||
|
|
||
| * Type name: application | ||
| * Subtype name: gnap-binding+jwsd |
There was a problem hiding this comment.
| * Subtype name: gnap-binding+jwsd | |
| * Subtype name: gnap-binding+jws |
draft-ietf-gnap-core-protocol.md
Outdated
| To indicate that the content is a GNAP token rotation message to be bound with a detached JWS mechanism: | ||
|
|
||
| * Type name: application | ||
| * Subtype name: gnap-binding-rotation+jwsd |
There was a problem hiding this comment.
| * Subtype name: gnap-binding-rotation+jwsd | |
| * Subtype name: gnap-binding-rotation+jws |
draft-ietf-gnap-core-protocol.md
Outdated
|
|
||
| ## Structured Syntax Suffix Registration | ||
|
|
||
| This section requests registration of the "+jws" and "+jwsd" structured syntax suffixes in |
There was a problem hiding this comment.
| This section requests registration of the "+jws" and "+jwsd" structured syntax suffixes in | |
| This section requests registration of the "+jws" structured syntax suffix in |
|
@selfissued I'm fine with changing the values here, but the question is more what the appropriate containment is at the protocol level. I don't believe the signaling you are referring to works in this case. There are two JOSE-based mechanisms defined by GNAP, one uses JWS as the message payload, effectively replacing the JSON with its own type -- that's the "Attached JWS" payload. The other keeps the payload as-is (JSON) but uses JWS to create a detached signature. The payload of the JWS then becomes a hash of the content instead of the content itself. Within GNAP these are signaled by separate field values, but shouldn't they be separate If we remove |
|
Your suggestion above not using structured suffixes would be fine. Or use something like The core of my review is to not create a separate Oh, and to be clear in the registration text that |
No description provided.