Orie launched the debate when he wrote :
- instead of seeing: application/secevent+jwt,
- we should be seeing: application/jwt; profile=secevent**
*
*
*About Media types
*
"/When the only thing you have is a hammer, every problem looks
like a nail/".
When the only thing you have is RFC 6838, every interoperability
problem looks like a Media Type.
It is useful to recall section 4.4 (Canonicalization and Format
Requirements) from RFC 6838 (Media Type Specifications and Registration
Procedures) :
*4.4.All registered media types MUST employ a single, canonical data
format, regardless of registration tree.
A permanent and readily available public specification of the format
for the media type MUST exist for all types registered in the
standards tree.This specification _MUST pr__ovide sufficient detail_**so
that interoperability between independent implementations using the
media type is possible.
*
It is interesting to take a look at the media type: application/jwt
which is defined in RFC 7519 (JWT).
*oType name: application
oSubtype name: jwt
oRequired parameters: n/a
oOptional parameters: n/a
oEncoding considerations: 8bit; JWT values are encoded as a series
of base64url-encoded values (some of which may be the empty string)
separated by period (’.’) characters.
oSecurity considerations: See the Security Considerations section of RFC
7519
oInteroperability considerations: n/a
oPublished specification: RFC 7519
oApplications that use this media type: OpenID Connect, Mozilla
Persona, Salesforce, Google, Android, Windows Azure, Amazon Web
Services, and numerous others
oFragment identifier considerations: n/a
oAdditional information:
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a*
Since the registration template mentions: "*Interoperability
considerations: n/a*", it looks like the application/jwt media type
defined in RFC 7519
is not conformant to RFC 6838.
Section 6.2 from RFC 6838 also mentions:
*
**Interoperability considerations**
Any issues regarding the interoperable use of types employing this
structured syntax should be given here.Examples would include
the existence of incompatible versions of the syntax, issues
combining certain charsets with the syntax, or incompatibilities
with other types or protocols.
*
*It is questionable why the Media Type Registration Procedures have not
been followed to register a media type like JWT **
**which does not conform to section 4.4 from RFC 6838.*
Let us take a look at an ETSI case when using media types. ETSI has
registered several media types under the IANA application/vendor tree:
*https://portal.etsi.org/pnns/MIMEmediatypeapplications
*
Two of them are interesting :
*vnd.etsi.tsl + derRegisteredTS 102 231
vnd.etsi.tsl + xmlRegisteredTS 102 231
*
The TSL (Trust-service Status List) has been defined using two formats:
ASN.1/DER and XML.
The functionality (i.e. Trust-service Status List) is placed first and
the serialization format (i.e. DER or XML) is placed after.
But, more important, an ETSI URI is associated with ETSI TS 102 231:
*https://uri.etsi.org/02231/v3.1.2/
*
This URI link is resolvable. When you click on it, you can download two
files:
*12/18/20094:25 PM1224744 ts_102231v030102p.pdf
<https://www.etsi.org/deliver/etsi_ts/102200_102299/102231/03.01.02_60/ts_102231v030102p.pdf>
12/18/20098:11 AM36079 ts_102231v030102p0.zip
<https://www.etsi.org/deliver/etsi_ts/102200_102299/102231/03.01.02_60/ts_102231v030102p0.zip>
*
and if you now click on the link of the zipped field, you can access to
five files:
*ts_102231v030102_additionaltypes_xsd.xsd
ts_102231v030102_asn
ts_102231v030102_sch.schema
ts_102231v030102_sie_xsd.xsd
ts_102231v030102_xsd.xsd
*
which means that a developer has an easy access both the XML schema and
the ASN.1 module that contains all the ASN.1 definitions.
In this way, not only the media type is correctly named, but also "
*This specification provides sufficient detail
so that interoperability between independent implementation using the
media type is possible".*
(See section 4.4. from RFC 6838).
Coming back to the debate raised by Orie using either:
*application/secevent+jwt*or
*application/jwt; profile=secevent*.
The functionality should come first, i.e. *, **secevent*, with a suffix
indicating the serialization format.
However, adding the suffix "+jwt" would be insufficient to achieve
interoperability.
Section 3.12 of RFC 8725 mentions that distinct "*typ*" values should be
used to differentiate between the different kinds of JWTs.
Since "typ" (type) Header Parameter defined by [JWS] and [JWE] is used
by JWT applications to declare the media type [IANA.MediaTypes]
of the complete JWT, this does not help.
It is questionable whether jwt should be mentioned for a serialization
format.
Another email will address interoperability between independent
implementations. It will also be copied to the media-ty...@iana.org
mailing list
since it addresses:
*oInteroperability considerations*
Its header will be: "About interoperability between independent
implementations".
Denis
ya know - there was a time when a standard could have a conformance
test and then the implementations worked together.
Now standards are just wishful thinking. Something MIGHT work, or
might not.
interop was a feature of a standard. Now the standard is wishful
thinking and interop profile comes after the std is published. (maybe)
..tom
On Tue, Nov 28, 2023 at 11:15 AM David Waite
<da...@alkaline-solutions.com> wrote:
Media type parameters are useful for subtypes that add a multitude
of expansion options, such as multimedia formats with a multitude
of codecs, encoding options, and profiles to define feature sets.
The best usages of them I’ve seen is supplemental.
A baseline JWT isn’t really able to be customized in that way;
even though it has defined claim names and meanings there
conventions and considerations expected to be defined by a
particular application of JWT
Secevents or a JWT credential might define parameterization. For
example, a credential might describe itself as having particular
types/profiles of claims about a subject, such as being usable as
a driving license and as a primary government-issued identification.
-DW
On Nov 28, 2023, at 1:24 PM, Tom Jones
<thomasclinganjo...@gmail.com> wrote:
I agree with Mike. This exercise seems to add confusion rather
than clarity.
thx ..Tom (mobile)
On Tue, Nov 28, 2023, 10:05 AM Michael Jones
<michael_b_jo...@hotmail.com> wrote:
Orie, you wrote:
TLDR; TallTed believes that the convention in the JWT BCP is
not correct:
https://datatracker.ietf.org/doc/html/rfc8725#name-use-explicit-typing
So instead of seeing:
application/secevent+jwt
We should be seeing:
application/jwt; profile=secevent
For what it's worth, the authors of the JWT BCP believed
that the use of application//subtype/+jwt works well for
explicit typing, and so put it into the specification. The
IETF-wide review and the IESG review supported this
decision. I don’t see grounds to revise it.
I personally believe that adding media type parameters when
using media type names reduces interoperability. Code gets
the string comparison for media type names right and tends to
screw up on media type parameters in various ways because
they’re largely unexpected. Rather than adding the use of
media type parameters, I would prefer that the registrations
be updated to prohibit their use.
-- Mike
-----Original Message-----
From: OAuth <oauth-boun...@ietf.org> On Behalf Of Carsten Bormann
Sent: Monday, November 27, 2023 7:32 AM
To: Orie Steele <orie@transmute.industries>
Cc: oauth <oauth@ietf.org>; IETF Media Types
<media-ty...@ietf.org>
Subject: Re: [OAUTH-WG] Request to add a profile parameter to
+jwt and +sd-jwt
On 2023-11-27, at 15:55, Orie Steele
<orie@transmute.industries
<mailto:orie@transmute.industries>> wrote:
>
> application/jwt; profile=secevent
>
> This is a general form of the challenges associated with
using multiple structured suffixes with JWTs.
Anything that reduces our need to extract semantics from
complex nested structured suffixes is good.
Independent of which form is being used here, I’d like to
raise the specter of ossification:
Will we be able to evolve the profile name (nested media type
subtype) once a subtype/profile is in wide use?
(I think in the end we will exactly do that TLS 1.3 did: send
fake TLS 1.2 identification and do the recognition of TLS 1.3
on a higher level.)
Grüße, Carsten
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=05%7C01%7C%7C7dbe85583aa74167f5b608dbef5e1c2a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638366959703680014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FMVqVsRxxd7Y4hxEC2T5iSUB0wV84ASM5FQW8TYqRkY%3D&reserved=0
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
