Hi Orie, very interesting. I think there is a strong overlap with the COSE profiles I-D that Henk presented in Yokohama. Is there maybe a way to merge the two efforts?
cheers, t On Mon, Jul 10, 2023 at 2:37 PM Orie Steele <[email protected]> wrote: > Hello RATs & SCITT friends, > > I wanted to share a fresh draft with both lists. > > https://datatracker.ietf.org/doc/draft-jones-cose-typ-header-parameter/ > > This draft is related to several topics that have been recently discussed: > > - structured suffixes such as +cwt and +cose > - > https://mailarchive.ietf.org/arch/msg/media-types/WYpYmm8kOuATyx7vSbjmpp7Xa4k > - > https://mailarchive.ietf.org/arch/msg/media-types/11DZ2sHMIy-4E52MrCp1Dy7IQg4 > - multiple suffixes - > https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes > - JWT BCP - https://datatracker.ietf.org/doc/html/rfc8725 > <https://datatracker.ietf.org/doc/html/rfc8725> > - EAT - > https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat#section-4.3 > > In particular, this section on explicit typing is relevant: > https://datatracker.ietf.org/doc/html/rfc8725#section-3.11 > > > Note that the use of explicit typing may not achieve disambiguation from > existing kinds of JWTs, > > as the validation rules for existing kinds of JWTs often do not use the > "typ" Header Parameter value. > > Explicit typing is RECOMMENDED for new uses of JWTs. > > There are cases where you might have used +jwt as a structured suffix to > accomplish this for a new JWT type, but then not been able to do the same > with +cwt. > > For example, imagine new token media types: > > application/foo+bar+jwt > application/foo+bar+cwt > > If the `typ` draft above is successful, > > Processors will be able to rely on `typ: application/foo+bar+jwt` and > `typ: application/foo+bar+cwt` consistently in both JOSE and COSE. > > This is probably more relevant to processors that have a high chance of > confusing one token type for another, or that process many different token > types. > > It's also possible this `typ` property might be used to secure none token > formats, for example: > > application/foo+bar+jose > application/foo+bar+cose > > Where the payload might already be using `cty` or `content_type`, for > example, > imagine you have an envelope format that secure a JSON or YAML payload, > but has headers that need to be processed consistently, you might see this: > > typ: application/foo+yaml+jose > cty: application/yaml > > typ: application/foo+json+cose > content_type: application/json > > `typ` is for the type of the envelope, whereas `cty` and `content_type` > are for the type of the `payload`. > > Ensuring similar interfaces exist on both sides makes upgrading to COSE > easier. > > We welcome any feedback, including comments about why the JWT BCP's > guidance should not be translated to CWT or other details we may have > missed so far. > > Regards, > > OS > > > -- > > > ORIE STEELE > Chief Technology Officer > www.transmute.industries > > <https://transmute.industries> > _______________________________________________ > RATS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rats > -- Thomas
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
