+1 to the commentary on keeping payloads opaque until after security checks.
One interesting difference between jose and cose, is that jose has:
typ: the content type of the token.
cty: the content type of the payload.
For most JWT use cases the cty value is sorta redundant, since we expect
the
> As I mentioned before, the multiple suffixes draft might not land... So it
> would be better to avoid multiple plus
I was following your lead from earlier in the thread.
From: Orie Steele
Date: Monday, April 3, 2023 at 5:09 PM
To: "Smith, Ned"
Cc: Laurence Lundblade , Esko Dijk
, Michael
I think the main goal for EAT is to allow a general EAT handler to know if EAT
is CBOR/CWT or JSON/JWT. Either “eat+cbor” or “eat+cwt” will do that. Probably
“eat+cwt” is better because it is more specific.
The pipeline thing makes sense when the connections between stages are easy and
general
Inline
On Tue, Apr 4, 2023 at 2:55 AM Esko Dijk
wrote:
> > So you can read the subtype "eat" and then consider it as +cwt, +cose,
> +cbor, for an example media type of "application/eat+cbor+cose+cwt"
>
>
>
> It looks like in your example the order is reversed; given the existing
> examples
Esko Dijk wrote:
> As you said also the following would be possible today:
> application/voucher+ysid
> if we register 'ysid' as being CBOR-YANG-SID that's included in a COSE
> wrapper. I find this less useful than the first options of '+cbor' or
> '+cose' , it seems
> So you can read the subtype "eat" and then consider it as +cwt, +cose, +cbor,
> for an example media type of "application/eat+cbor+cose+cwt"
It looks like in your example the order is reversed; given the existing
examples defined in draft-ietf-mediaman-suffixes-03 Section 2.1?
Let’s assume
> I don't understand why it's not application/voucher+cose+cbor.
> The outer encoding is cbor, the next layer is cose.
Well, the reason is clearly that the draft-ietf-mediaman-suffixes is just a
draft at the moment. Things may change there. We don't want to overhaul our
draft in this stage or
