Despite it has been clarified in #311 that this document is a "specification", there are still some "profile" (and also "document") being used to point to it (e.g., "profile" appearing in the section 3.4 Out of Scope, the first sentence and notes of the section 6.1 IETF SD-JWT VC Profile, and more. "document" in the second sentence of the section 1. Introduction and, the note in the section 5.)

Before the final publication, it might be better to review the entire document to check that the terms "specification", "profile", and "document" are properly used or not.

Examples of the possible improper usage of "profile" and "document" (bolded).

1. Introduction

This document is an interoperability profile that can be used by implementations in various contexts, be it a certain industry or a certain regulatory environment. Note that while this profile is aimed at high assurance use-cases, it can also be used for lower assurance use-cases.

3.1. Assumptions

The Issuer is talking to the Wallet supporting the features defined in this profile (via Wallet invocation mechanism)

3.4. Out of Scope

Although X.509 PKI is extensively utilized in this profile, the methods for establishing trust or obtaining root certificates are out of the scope of this specification.

5. OpenID for Verifiable Presentations

Note that while this document does not define profiles for X.509 certificates used in Verifier authentication (e.g., with the x509_hash Client Identifier Prefix), ecosystems are encouraged to select suitable certificate issuing policies and certificate profiles (for example, an mDL ecosystem can use the Reader Authentication Certificate profile defined in Annex B of ISO/IEC 18013-5 with x509_hash), or define new ones if there is a good reason to do so.

6.1. IETF SD-JWT VC Profile

Note: If there is a requirement to communicate information about the verification status and identity assurance data of the claims about the subject, the syntax defined by [OIDF.ekyc-ida] SHOULD be used. It is up to each jurisdiction and ecosystem, whether to require it to the implementers of this profile.

Note: In some Credential Types, it is not desirable to include an expiration date (e.g., diploma attestation). Therefore, this profile leaves its inclusion to the Issuer, or the body defining the respective Credential Type.

6.1.1. Issuer identification and key resolution to validate an issued Credential

This profile mandates the support for X.509 certificate-based key resolution to validate the issuer signature of an SD-JWT VC.

7. Crypto Suites

Ecosystem-specific profiles MAY mandate additional cryptographic suites.
When using this profile alongside other crypto suites, each entity SHOULD make it explicit in its metadata which other algorithms and key types are supported for the cryptographic operations.

8. Hash Algorithms

Ecosystem-specific profiles MAY mandate additional hashing algorithms.
When using this profile alongside other hash algorithms, each entity SHOULD make it explicit in its metadata which other algorithms are supported.

9.3. Ecosystem Implementation Considerations

This document intentionally leaves certain extensions for ecosystems to define, in order to enable broad compatibility across differing or even conflicting requirements.