I can nothing but to reinforce that notion! :-)
On 10.07.23 19:07, Thomas Fossati wrote:
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/
<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/WYpYmm8kOuATyx7vSbjmpp7Xa4k/>
-
https://mailarchive.ietf.org/arch/msg/media-types/11DZ2sHMIy-4E52MrCp1Dy7IQg4
<https://mailarchive.ietf.org/arch/msg/media-types/11DZ2sHMIy-4E52MrCp1Dy7IQg4/>
- multiple suffixes -
https://datatracker.ietf.org/doc/draft-ietf-mediaman-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
<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
<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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/rats
<https://www.ietf.org/mailman/listinfo/rats>
--
Thomas
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
