When using media types (RFC 6838), interoperability can be achieved, *IF
AND ONLY IF* the "*Interoperability considerations"*of the registration
template line
is filled in with appropriate information.*
*
It should be noticed that some "old" media types registrations made a
correct usage of RFC 6838, like the"*application/pdf*" media type, which
includes a magic number:
*Magic number(s):
All PDF files start with the characters '%PDF-' using the PDF version
number,
e.g., '%PDF-1.4'.These characters are in US-ASCII encoding.
File extension(s): .pdf
*
Are there suffixes append to "pdf" to know more; for example, to know if
the document is conformant to PDF/A ? The answer is no,
since every pdf document contains a pointer to locate the position of
the PDF Dictionary and the PDF Dictionary will tell it.
The previous ETSI example about TS 102 231 (in the thread [OAUTH-WG]
Request to add a profile parameter to +jwt and +sd-jwt)
see:
https://mailarchive.ietf.org/arch/msg/oauth/s6rxX-aiNse3ToSUmSVr28LioaM/
is a good example,since the associated URI provides
a direct access to both an ASN.1 module and an XML Schema.
ISO has defined the mDL. While no media type has been defined for the
ISO mDL, interoperability can nevertheless be achieved.
How to recognize that a document is a mDL ?
First, from the application context and then, because the decoded object
(encoded using CBOR) starts with:
|*{
*||**|*"version"*|*: *|*"1.0"*|*,
*|*"documents"*|*: [
{
*|*"docType"*|*: *|*"org.iso.18013.5.1.mDL"*|*,
*|
The structure adopted for "*docType*" not only achieves uniqueness, but
also allows to take into consideration future versions of ISO 18013 Part
5, if needed.
This single reference is sufficient since all the data elements being
described belong to a single nameSpace : “org.iso.18013.5.1”.
_Note_: If applied to RFC numbers, the same approach would not work,
since an RFC number changes when there is a revision.
*Current practices to define**data structures*
In ISO 18013 Part 5, CDDL (Concise Data Definition Language) is used to
define data structures that can then be translated into CBOR and JSON.
The W3C is using W3C URIs to define schemas using several name spaces,
e.g., using JSON-LD schemas.
The IETF has been using OIDs to identify ASN.1 modules using several
name spaces. As an example:
*{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}
*
_Note_: The following OIDbranch *{iso(1) identified-organization(3)
dod(6) internet(1)}*is an OID in the tree from the USDepartment of Defense,
instead from the IETF, but this was the practice at that time. More
information is available at: https://www.alvestrand.no/objectid/1.3.6.html
*The key question is how to achieve interoperability between independent
implementations ?
*
The answer is: by using a language A able to describe data structures
which indicates which data elements are mandatory, conditional,
recommended or optional,
how many instances of them are accepted; and by using another language B
that tells how to serialize the data structure when populated with some
values.
More constrains may also apply when using the language A, like the
syntax to be used for each data value and, in some cases, allowed set of
values or allowed range values.
The language A can be, e.g., : ASN.1, XSD, JSON Schema
(https://json-schema.org/specification), JSON-LD, CDDL ?
The language B can be, e.g., : DER, XML, JSON, CBOR.
CDDL is mentioned with a question mark, as it does not seem to be able
to use external name spaces. See below.
Obviously, the use of only a language A would be insufficient, since the
processing of the data elements described using that language need to be
detailed in the specification.
Languages of type A allow to define templates or schemas that allow to
make sure that a data structure is compliant with a definition based on
that language,
both for an automatic generation and for an automatic validation. Hence,
the data structure definition must be uniquely identifiable.
A data structure definition may use internally names that are defined in
a single name space (e.g., “org.iso.18013.5.1”)
or in several name spaces (e.g., in W3C VCDM 2.0 using JSON-LD or when
using ASN.1 modules).
Unless a document is only sectorial (e.g. a mobile Driving License), the
use of several name spaces should be supported.
*A suggested way forward
*
Nowadays, in order to achieve interoperability between independent
implementations, the use of machine processable data and or protocol
descriptions,
e.g., using templates, schemas or modules should be RECOMMENDED. This
would be a way to speed up implementations and to prevent some errors.
At this time, a distinction needs to be done between technical
specifications that are freely accessible (e.g. RFCs, W3C
recommendations, ETSI documents)
and documents that are only accessible after payment, e.g., ISO
standards. In the case of the IETF, these templates or schemas should be
freely accessible and
*the IESG should consider how to make this possible using ISO URIs in a
manner similar to what ETSI has done.**
*
See: *https://uri.etsi.org/02231/v3.1.2/ *as an example.
Then after, RFCs will be able to include into the specification these
templates, schemas or modules, but also derive files from them that
could be downloaded
from a web sitemanaged by the IETF so that they can be easily used by
implementers (i.e. without manually removing page headers and footers).
Denis
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
