Per the JWT BCP, regarding typ.
https://datatracker.ietf.org/doc/html/rfc8725#name-use-explicit-typing
The +jwt suffix goes on the end.
You would need to register +eat as a structured suffix otherwise.
My understanding is that you currently intend to register application/eat
as a subtype, not
> application/eat+cbor+cose+cwt
EAT is a specialization of a CWT or a JWT. What in eat is encoded before the
cbor (which encodes the token)?
If the conceptual message is identified by a message wrapper
draft-ftbs-rats-msg-wrap-02 - RATS Conceptual Messages Wrapper
Inline:
On Mon, Apr 3, 2023 at 3:10 PM Smith, Ned wrote:
> > there’s no standard for the key material and key identification
>
> The observation is that the COSE block contains a key-id that can be used
> to locate the key material (e.g., I assume key material refers to the
> public key needed
Laurence Lundblade wrote:
> I’m not sure identifying something as COSE, or even CWT is that useful
> because there’s no standard for the key material and key identification
> that cuts across all uses of COSE or CWT.
Knowing that it's COSE, a dissector can know:
1) it's an array
> there’s no standard for the key material and key identification
The observation is that the COSE block contains a key-id that can be used to
locate the key material (e.g., I assume key material refers to the public key
needed to verify the COSE signature given asymmetric crypto). The COSE
> +cwt is also three layers: CBOR, COSE, and then CWT claims inside the signed
> part. So, if we'd call it application/eat+cwt, then we ought also call it
> application/voucher+ysid
Wouldn't it be "application/cbor+cose+ysid+voucher" given the +cwt context and
ordering convention in
I’m not sure identifying something as COSE, or even CWT is that useful because
there’s no standard for the key material and key identification that cuts
across all uses of COSE or CWT.
For example with EAT the receiver probably will need an endorsement (a very
specific thing with very
Orie Steele wrote:
> At IETF 116 this draft was discussed:
> - https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes -
> https://youtu.be/BrP1upACJ0c?t=1744
> TLDR; there is work in progress to define multiple suffixes, and how
> they are interpreted.
Right, I read
Yes! That seems to have been one proposal, related to cleaning up the
registry and clarifying interpretation.
If you have strong opinions on this, please help contribute to the dialog
on this media types list:
https://mailarchive.ietf.org/arch/msg/media-types/qO72m31whV5QZmV6kj55KDqS8n8/
Interesting!
It would be nice if I-D.ietf-mediaman-suffixes could define a backward
compatibility convention that shows how existing / registered media-type-names
can co-exist with I-D.ietf-mediaman-suffixes.
From: Orie Steele
Date: Monday, April 3, 2023 at 10:47 AM
To: "Smith, Ned"
Cc: Esko
At IETF 116 this draft was discussed:
- https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes
- https://youtu.be/BrP1upACJ0c?t=1744
TLDR; there is work in progress to define multiple suffixes, and how they
are interpreted.
This would be relevant to potential future +cwt media types, it
It seems the early registrations focused on encoding formats for content to the
right of the "+" like '+xml', '+json', '+cbor', '+der', while later
registrations seem to include schema formats like '+jwt', '+sqlite3', and
'+tlv'.
It would have been nice if the registry defined the right side
Hi,
As for the questions mentioned on these slides:
1. "Is is '-cose+cbor' or '-cbor+cose'
The registry
https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml
lists the subtypes that one have after the '+' sign.
'cbor' is there but 'cose' is not.
13 matches
Mail list logo
