A Simple Picture: What Originator Profile Provides

illustrates the capabilities of the [=Originator Profile Framework=] in a simple picture.

Firstly, [=Originator Profile Framework=] provides rich information about the [=Originator=] — [=Originator Profile=] — which the name comes from (①). It includes not only the basic attributes about the organization but also various attributes validated by multiple third parties that are useful for the [=Recipient=] to assess the [=Content=].

Secondly, [=Originator Profile Framework=] provides a way to provide integrity verification of the [=Content=] and also the origin of the [=Content=] as an [=Originator Profile=] (②).

Finally, the [=Recipient=] of the [=Content=] can verify the integrity and authenticity of the [=Content=] using the information provided, and also refer to the [=Originator Profile=] to know about the attributes of the [=Originator=] (③).

The framework is designed to be extensible and adaptable to various use cases; for the [=Originator Profile=], it allows adding [=Validated Attributes=] provided by multiple parties. For [=Content=] integrity, the framework is extensible to accept different types of media in different types of serialization. For example, the Web Media specific models allow for the protection of text fragments and other media within a web page.

Abstract Model: Signed Data with Policy

In this document, we define [=Signed Data=] and [=Signed Data with Policy=] based on "Cryptographically Signed Data" as discussed in detail in the paper [[A Model For Claim Validation]]. We define [=Core Profile=] and [=Profile Annotation=] based on the "Certificate" concepts presented in the same paper. In the following sections, we will elaborate on definitions and their implications.

The terminology used in the paper [[A Model For Claim Validation]], "verify" and "validate," in particular, is different from the terminology used in this document. In the paper, the author dictates that the difference between these two acts is a lack of context in validation. In this document, we use "verify" to mean the act of checking the integrity of [=Signed Data=] using the [=Verification Key=], and "validate" to mean the act of assessing the truthfulness of a piece of information by directly checking the [=Entity=] itself or consulting highly reliable sources, such as government databases. This distinction is essential in the context of [=Originator Profile Framework=], as it helps clarify the roles and responsibilities of different [=Entities=] involved in the ecosystem.

There are interesting but very confusing aspects in the difference between "verify" and "validate" within Japan. It is regrettable that these two words are often translated into the same Japanese word 「検証」 (pronounced as 'ken-sho') and are used interchangeably, leading to misunderstandings in this digital signature application area. Thus, i.e., AI translation of this document can not reflect the nuances of "verify" and "validate" as outlined in this document.

Signed Data

In [[A Model For Claim Validation]], "Cryptographically Signed Data" is a conceptual model in which an originator signs a payload and bundles three elements: (1) a verification key (or a reference to it), (2) the payload (the subject being attested), and (3) the digital signature over that key and payload. This structure lets a recipient check source authenticity and payload integrity using the corresponding verification key.

Crucially, "Cryptographically Signed Data" alone does not establish the truth of any claim encoded in the payload; it only confirms the authenticity of the source and the integrity of the data. Determining whether a claim is valid requires additional evidence and a validator-specific validation policy (i.e., criteria/intent), which is distinct from mere cryptographic verification.

In this document, A [=Signed Data=] consists of three elements — [=Verification Key=] or reference to it, payload, and signature — and provides a way to verify that the signature is created on the payload, with the [=Signing Key=] that is bound to the [=Verification Key=], Thus the integrity of the payload is ensured, and use the [=Verification Key=] to identify the [=Entity=] which signed the data.

Signed Data with Policy

In [=Originator Profile Framework=], all of the data models are based on [=Signed Data=] under a specific policy. We refer to this as [=Signed Data with Policy=]. A [=Signed Data with Policy=] can provide a way to express the intent and context of a signature based on predefined and shared policies. [=Signed Data with Policy=] is an abstract concept of digital credentials (i.e., [[vc-data-model-2.0]]) and/or digital certificates (i.e., [[X509V3]]).

In [[A Model For Claim Validation]], the authors detailed the relationship between signed data with policy and the related processes. A "Certificate" is a form of signed data issued by a certifier that (i) asserts the certifier has validated a specific claim and (ii) attests that validation according to the certifier’s certification policy (its criteria). Concretely, it bundles three elements — (1) the certifier’s verification key (or a reference), (2) a payload stating what has been certified, and (3) the certifier’s digital signature over that key and payload. Its signature intends to show not just who issued it, but that the issuer certifies the claim according to its policy; validators can then accept the claim by verifying the certificate and trusting the certifier under their own validation policy.

We avoid using the term "Certificate" or "Credentials" to describe the signed data within the [=Originator Profile Framework=]. The term "Certificate" in digital contexts typically refers to a public key certificate (i.e., [[X509V3]]), and the term "Credentials" often implies a broader set of claims or attributes. But in a non-digital world, many of the concepts around certification and credentials are more fluid and context-dependent. The confusion is particularly true in relation to the specific non-digital activities regarding "certification." Thus, using these terms could lead to misunderstandings about the nature and scope of the signed data being discussed here.

Limitations of X.509 PKI to Implement Originator Profile Framework

When using a digital signing scheme, there is a need to find the [=Verification Key=] of the signer and ensure that the corresponding [=Signing Key=] belongs to the correct [=Entity=]. To implement this, we typically rely on X.509 [[X509V3]] public key certificate scheme, which is widely used in various applications, and well understood. However, to implement the [=Originator Profile Framework=], the current design of X.509 lacks flexibility. This section discusses the limitations we want to address.

While we discuss the limitations of X.509 here, and the current Originator Profile implementation does not yet support all aspects of it, it is still possible to leverage X.509 technology and its ecosystem within the [=Originator Profile Framework=] to achieve certain goals with limitations. Please refer to for more details.

• Flexible addition of Attributes is difficult

  With X.509 certificates, it is challenging to add attributes required for specific application purposes freely. Even it is possible to add some attributes, the certificate issuer must validate all attributes included in the certificate. Furthermore, since X.509 certificates are expressed as a single certificate, it is not possible to split the certificate for representation or combine certificates from different issuers.

• Difficult to introduce an amended issuance policy

  While related to the discussion on adding attribute information, certificate issuance policies are generally stringent and offer no flexibility. There are use cases where specific communities operate specialized sets of public key certificates for particular purposes, signaling that the public key used for signing satisfies specific policy requirements. To implement this type of "virtual list of certificates," it may be necessary to establish an entire certificate tree, including the operation of a Certificate Authority (CA). Since operating such a CA involves significant work and complexity, it is often not feasible for smaller communities or specialized use cases.

• Satisfying certificate status checking scalability requirement is challenging

  Public key certificates require periodic or on-demand validity checks. Protocols like [[OCSP]] and CRL [[RFC5280]] are currently in use. However, even within the scope of public key certificates used by web servers, OCSP fails to meet scalability requirements, and CRLs pose privacy concerns. There are some discussions on improvement, but there are no reasonable solutions yet as discussed in a paper [[SoK-DR]]. These factors contribute to the trend toward shorter certificate lifetimes. Furthermore, in the domain targeted by [=Originator Profile Framework=], considering that a much larger number of [=Entities=] will generate significantly more signed data, which a vastly greater number of clients will verify, the scale involved is expected to be orders of magnitude larger. Therefore, a new approach that does not rely on current mechanisms is necessary.

In [=Originator Profile Framework=], these limitations are addressed by a more flexible and extensible framework.

Architectural Design of Originator Profile Framework

While [=Originator Profile Framework=] aims to provide content provenance, it addresses the limitations of current digital public key certificate schemes by providing a more flexible and extensible framework to provide validated attributes. All of the signed data are [=Signed Data from Originator=], that is a kind of [=Signed Data with Policy=]; thus, it is signed with intent under the corresponding policy of the [=Originator=].

The [=Originator Profile Framework=] architecture currently comprises three groups of models: the [=Base Model=], a domain-agnostic model; the [=Jurisdiction Specific Model=], which extends the [=Base Model=] to support specific jurisdictions; and the [=Web Media Specific Model=], a model that extends the [=Base Model=] for Web Media. We expect to introduce a similar supplemental model in each of the future application domains. Each of the models is detailed in its respective section: , , and .

In the following subsections, we will delve into some details of three key models: the [=Originator Profile=], [=Signed Data from Originator=], and [=Content Attestation=]. The details of these models are described in .

Originator Profile

In the [=Originator Profile Framework=], the information about the [=Originator=] that is to be verifiable is a [=Signed Data from Originator=]; the Originator issues the signed data under a specific policy. The Originator's information is expressed as an [=Originator Profile=]. An [=Originator Profile=] consists of a [=Core Profile=], which contains the [=Originator=]'s [=Verification Key=], and one or more [=Profile Annotations=] that attach [=Validated Attributes=] to the [=Core Profile=].

The [=Core Profile=] includes the [=Originator=]'s [=Verification Key=] and is one of [=Signed Data from Originator=], which will be described in the following section. [=Core Profile=] contains essential attributes of [=Originator Profile=]. [=Core Profile Issuers=] issues it under [=Core Profile Policy=].

The [=Profile Annotation=] is a set of additional attributes that are issued by [=Profile Annotation Issuers=] independently of the [=Core Profile Issuer=]. [=Profile Annotation=] is also based on [=Signed Data from Originator=]. A [=Core Profile=] may be bound to one or more [=Profile Annotations=] provided by multiple [=Profile Annotation Issuers=], as specified in the [=Profile Annotation Policy=]. [=Profile Annotation=] is an abstract concept, and various specialized types of [=Profile Annotations=] exist; this is one of the extension points for each application domain.

Signed Data from Originator

[=Signed Data from Originator=] is an essential data model within [=Originator Profile Framework=]. It is an abstract data model based on [=Signed Data with Policy=], originated from an [=Originator=], assuming that it is signed with a specific intent corresponding to the policy stated by the [=Originator=]. The reference to the [=Originator Profile=] is included in the [=Signed Data from Originator=].

Content Attestation

A [=Content Attestation=] is a type of [=Signed Data from Originator=] that confirms the [=Content=] originated from the corresponding [=Originator=] and also has not been altered. A [=Content Attestation=] can be [=Verified=] by using the [=Verification Key=] contained in the [=Core Profile=], which is part of the [=Originator Profile=]. The [=Recipient=] can verify the integrity of the [=Content=] alongside the [=Originator Profile=] to know the profile of the [=Originator=], including the [=Originator=]'s policy.

[=Content Attestation=] is provided within or alongside the [=Content=] itself. [=Content Integrity Descriptor=], which is part of the payload of the [=Content Attestation=] provides additional information about the content's integrity. Please refer for [=Content Integrity Descriptor=] discussion for the web media.

Entities

The following are the key [=Entities=] in the Base Model.

• [=Originator=]
• [=Recipient=]
• [=Originator Profile Issuer=]
  • [=Core Profile Issuer=]
  • [=Profile Annotation Issuer=]

Data Models

This section describes four data models for the [=Base Model=]: [=Signed Data from Originator=], [=Core Profile=], [=Profile Annotation=], and [=Content Attestation=].

Processes

This section describes two processes for the [=Base Model=]: Issuing [=Originator Profile=] and Delivering [=Content=] with [=Content Attestation=].

Issuing Originator Profile

This process involves the following steps:

1. The [=Originator=] creates a key pair ([=Signing Key=], [=Verification Key=]).
2. The [=Originator=] sends a request with an application that includes an adequate amount of information, including the [=Verification Key=] to [=Core Profile Issuer=] to issue a [=Core Profile=]. The application needs to include enough information to satisfy the [=Core Profile Policy=] on issuing [=Core Profile=].
3. The [=Core Profile Issuer=] [=Validates=] whether the [=Originator=]'s application meets the requirements in the [=Core Profile Policy=] and issues a [=Core Profile=].
4. The [=Originator=] requests one or more [=Profile Annotations=] from [=Profile Annotation Issuers=].
5. Each [=Profile Annotation Issuer=] [=Validates=] the relevant attributes and issues [=Profile Annotations=].
6. The [=Originator=] collects the [=Core Profile=] and [=Profile Annotations=] to form the [=Originator Profile=].

Delivering Content with Content Attestation

Assuming that the [=Originator=] has already obtained an [=Originator Profile=], this process involves the following steps:

1. The [=Originator=] prepares the [=Content=] for delivery.
2. The [=Originator=] sends the attested [=Content=] with [=Content Attestation=], to the [=Recipient=]. The [=Originator=] also sends the [=Originator Profile=] as necessary.
3. The [=Recipient=] verifies the [=Content Attestation=].
4. The [=Recipient=] verifies the [=Originator Profile=], which includes [=Core Profile=] and [=Profile Annotations=] as necessary.

Policy

In this section, we discuss high-level policies for [=Base Model=] governing the issuance and management of [=Core Profile=] and [=Profile Annotation=]. These are not concrete policies but rather provide design direction that informs the development of specific policies and procedures. A discussion on the overall governance model is provided in .

Organization Profile

[=Organization Profile=] is one of the concrete types of [=Profile Annotation=] that provides validated information about the organization behind the [=Originator=].

While we recognize that an abstract data model is necessary to represent the key attributes of organizations across different jurisdictions, the requirements for this model require further analysis among jurisdictions to ensure that all relevant aspects are captured.

The model may include attributes such as:

• Name
• Address
• Contact Information
• Registration Details

With consideration for the specific requirements of each jurisdiction, especially regarding registration details, they can vary considerably. It is also essential to note that multilingual support is required for the audience outside of the specific jurisdiction.

Entities

In addition to the [=Entities=] discussed in , [=Web Media Specific Model=] introduces the following [=Entity=]:

• [=Content Aggregator=]

Data Models

Web Media Specific model defines two data models: [=Web Media Profile=] and [=Website Profile=].

Processes

This section describes two processes for the Web Media Specific Model: Delivering [=Content=] as a Web Page and Delivering [=Content=] via a [=Content Aggregator=].

Delivering Contents as a Web Page

This section describes the process of delivering [=Content=] as a web page.

This process involves the following steps:

1. The [=Originator=] prepares the [=Content=] for delivery
2. The [=Originator=] creates a [=Content Attestation=] with reference to [=Originator Profile=].
3. The [=Originator=] publishes the web page including the [=Content=], [=Content Attestation=], and [=Originator Profile=] (if necessary) on its website.
4. The web server delivers the web page to [=Recipient=].
5. The [=Recipient=] discovers [=Content=] with [=Content Attestation=]. Then, find or retrieve [=Originator Profile=]
6. The [=Recipient=] [=Verify=] the [=Originator Profile=].
7. The [=Recipient=] [=Verify=] the [=Content Attestation=] using the [=Verification Key=] in the [=Core Profile=], and [=Verify=] any [=Profile Annotations=].

Policy

Presentation

In this section, we provide the current status of the presentation aspects of the Originator Profile for Web Media, including currently implemented browser extensions and potential modifications to browsers.

A Generic Governance Model

The figure below shows a highly simplified generic governance model distilled from the discussion in the [[Trusted Web White Paper 3.0]]. (Note: the governance model discussed in the white paper is based on the discussion by one of the authors, in the paper [[A Study on Governance funded by JFSA]], which includes an analysis of [[ICANN]] multistakeholder model)

The governance in the digital ecosystem usually revolves around "Data Under Governance." The "Governing Body" is controlling the "Operator." The "Operator" manages the "Data Under Governance." The "Operator" is responsible for overseeing the management and protection of this data under the "Policy," which includes operational policy. The "Operator" operates under the policy faithfully, and the "Governance Body" is able to control "Data Under Governance" through the "Policy."

X.509 PKI based system with the Generic Governance Model

Following is an simplified representation of the governance model for an X.509 PKI system, based on the Generic model discussed in the previous section.

This figure presents a simplified governance structure of the X.509 Public Key Infrastructure (PKI) system. At the top of the hierarchy is the governing body, which establishes the overarching policies and trust framework for the PKI ecosystem. The Trust List, alongside with the governing body are the root of trust of the community which shared the same root of trust.

Under the governing body, Certificate Authorities (CAs) are responsible for issuing and managing digital certificates in accordance with these policies. The CAs act as trusted third parties, validating the identities of entities requesting certificates and ensuring compliance with governance requirements. Relying parties, such as users, applications, or organizations, depend on the trustworthiness of the CAs and the integrity of the certificates they issue to authenticate identities and secure communications. The figure illustrates the flow of trust, policy enforcement, and operational responsibilities among these entities, clarifying how governance is maintained and how trust is propagated within the X.509 PKI environment.

The verifying entity in the figure refers to the "Trust List" via the operating system or application, which includes the list of trusted root CAs. The operating system or application vendor typically manages the trust list, and it is updated through a software update mechanism.

Thus, from the verifying entity's perspective, which occurs through the operating library or application, the trust list is usually invisible; therefore, the operating system or application automatically trusts the root CAs in the trust list. Also, since the governing mechanism is hardbound to the entire trust tree, the only policy it can refer to and rely on is the policies defined by the governing bodies, which are maintaining the trust list, and each of the CAs.

Governance model for Web Media while in the bootstrap phase in Japan

The following is a simplified representation of the Originator Profile Governance Model planned for Japanese Media, within Japan, during the Bootstrap phase.

Firstly, in the Web Media ecosystem, [=Originator Profile=] is composed of four sets of [=Validated Attributes=] — [=Core Profile=], [=Organization Profile=], [=Web Media Profile=], and potentially, at least one "Media Association's Membership."

For the bootstrap phase in Japan, [=Core Profile=], [=Organization Profile=], and [=Web Media Profile=] are issued by the OP-CIP.

For the "Media Association's Membership," we plan to have it issued by one of the media associations in Japan. The actual issuance of a "Media Association's Membership" is potentially operated by OP-CIP on behalf of the media association, while the media association controls and is responsible for the validation of the membership.

The [=Originator=] (Media) requests the [=Core Profile=] and [=Web Media Profile=] from OP-CIP by providing the necessary information to satisfy the [=Core Profile Policy=] and [=Web Media Specific Policy=]. OP-CIP validates the information and issues the profiles to the [=Originator=]. OP-CIP also issues the [=Organization Profile=] by validating the organization's existence in Japan.

The [=Recipient=] will verify the [=Originator Profile=] of the [=Originator=] by referring to the [=Verification Key=] included in the [=Core Profile=] of the OP-CIP. Then, the [=Recipient=] verifies the [=Content Attestation=] using the [=Verification Key=] in the [=Core Profile=] of the [=Originator=].

The current implementation of the browser extension embeds the [=Verification Key=] of OP-CIP within the extension itself. Thus, the extension can verify the [=Originator Profile=] issued by OP-CIP without referring to any external trust list. Current implementation merely embeds and refers to the [=Verification Key=] of OP-CIP.

In the figures in the following sections, for brevity, we only show the issuing part of the governance models, which is marked "(A)" in .

Currently, issuance of an [=Originator Profile=], the OP-CIP mandates that the [=Originator=]'s commitment to the [[The Originator Profile Charter]]. This requirement is to ensure that all [=Originators=] adhere to a standard set of principles and practices, thereby fostering trust and reliability within the ecosystem. However, it is essential to note that this requirement is specific to the initial deployment phase and may be subject to change in the future as the ecosystem evolves and matures.

Governance Model for other Jurisdictions

The following is a simplified representation of the Originator Profile Governance Model, which is planned for use in other jurisdictions.

In this model, the [=Core Profile=] and [=Organization Profile=] are issued by OP-CIP, similar to the model for Japan. However, the [=Organization Profile=] (localized for jurisdiction XX) is issued by an [=Originator Profile Issuer=] in jurisdiction XX, which OP-CIP recognizes. The local [=Originator Profile Issuer=] is responsible for validating the attributes specific to the organization's existence in that jurisdiction, ensuring compliance with local regulations and standards.

We need to establish a mechanism to recognize the local [=Originator Profile Issuer=] by OP-CIP. This may involve a formal recognition process, where OP-CIP evaluates the local issuer's policies, procedures, and trustworthiness before granting them the authority to issue [=Organization Profiles=] localized for the jurisdiction. OP-CIP may issue a special kind of [=Profile Annotation=] to the local [=Originator Profile Issuer=] to indicate its recognition.

Governance Model for Global Community

The following is a simplified representation of the Originator Profile Governance Model planned for Global Community.

In this model, multiple [=Core Profile Issuers=] exist, each responsible for issuing [=Core Profiles=] to [=Originators=] and operating under its own governance. All [=Core Profile Issuers=] are recognized by "OP Root," which is represented by a special type of [=Originator Profile=], "Core OP Root," as shown in the figure. The [=Core Profile Issuers=] may also issue other types of [=Profile Annotations=], such as the [=Web Media Profile=], based on their governance and policies.

By establishing this model, centralization of the governance is avoidable, and diversity of the governance is achievable. Governance of "OP Root" should be designed to be inclusive, allowing for the participation of various stakeholders and the incorporation of diverse perspectives — similar to the multistakeholder governance model of [[ICANN]].

Establishing and operating such a multistakeholder governance model requires careful planning, ongoing collaboration, and a commitment to transparency and accountability from all participants. It is essential to create a shared understanding of roles, responsibilities, and decision-making processes to ensure the effective functioning of the governance framework. A lot can be learned from the experience of [[ICANN]]. One of the author's papers, [[A Study on Governance funded by JFSA]], may provide some insights into the challenges and opportunities associated with multistakeholder governance models and is helpful for starters who are interested in the context.

Comparison to C2PA

Coalition for Content Provenance and Authenticity (C2PA) is a consortium of leading media and technology companies collaborating to establish an open standard for content provenance and authenticity. The goal of C2PA is to provide a framework for creating, sharing, and verifying content authenticity metadata, enabling users to trust the content they consume.

The project primarily focuses on addressing the challenges of content provenance and authenticity in digital media, including ensuring the integrity of media files and providing verifiable information about their origins. Thus, the scope of C2PA overlaps with the [=Originator Profile Framework=] in its goals and objectives. Thus we hope to collaborate and align our efforts to achieve common objectives.

That said, there are some key differences between C2PA and the [=Originator Profile Framework=].

• C2PA focuses on media files, while [=Originator Profile Framework=] primarily aims to provide various content within the Web Media, including text, images, and videos. C2PA focuses on media files specifically.
• C2PA provides historical data, while [=Originator Profile Framework=] primarily focuses on verification by the end-user, rather than the internal work of Web Media. While historical data is essential, it appears to be more than sufficient for the end-user.
  

  Note: Some members of OP-CIP have an interest in providing content archives, and that naturally may include historical information. However, it will be implemented differently — probably, outside of the media data itself.

• [=Originator Profile Framework=] aims to provide rich information about the [=Originator=] through multiple [=Validated Attribute=] providers, accommodating various use cases and stakeholder requirements within a flexible framework.
• C2PA's trust model is based on X.509 PKI, thus it shares the same issues we discussed in
• C2PA's trust model is centralized, while there is an available trust list for C2PA, such as Adobe's Adobe Approved Trust List [[AATL]] and IPTC Origin Verified News Publishers List [[IPTC-OVNPL]]. It is a challenge to establish a trust list for specific use cases that meets the requirements of any new target ecosystem.

This document is not integrity protected and is not accompanied by an Originator Profile

This issue SHOULD be fixed appropriately.

Terminology Challenges

When working in standardization, there are always terminology challenges.

We understand that some terms are used differently or may be counterintuitive to specific stakeholders. The following terms require special attention:

• Certificate
• Validate and Verify

We attempted to be cautious when introducing concepts in , and provided additional notes. Please provide feedback not only on these terms but also on the overall document.

Also, note that some inconsistencies still exist in the terminology used within the currently available documents. The [[Originator Profile Blueprints]] are mostly consistent within the document series, but some of the terminology is used slightly differently from this Architectural Overview document. We will address these inconsistencies while incorporating the [[Originator Profile Blueprints]] into the [=Originator Profile Framework=] documentation series.

Internationalization and Multilingual Support

There are some internationalization and multilingual challenges in the use of [[vc-data-model-2.0]]. The current version of the data model suggests using a single language for each of the signed data objects. This decision is due to the fact that the current JSON-LD-based multilingual structure is complex to decode on the verifier side, which, in our case, is within a browser. The cost is not negligible; thus, we currently apply one language to the entire [=Profile Annotation=] model, which potentially contains multilingual strings. While it is possible to provide multiple PAs of the same type with different languages, the current extension does not yet support this.

Also note that, while the contents of the Web Media use case usually do not require extensive multilingual support since the contents are typically in one language per page, the information within the [=Originator Profile=] requires multilingual support regardless of the contents.

The other challenge is selecting the languages to be included. For Japanese, inclusion of both Japanese and English is necessary, but it is not clear for other languages.

We are exploring various options to address this issue and may propose a different scheme that is more suitable for our use case.

Key delivery and discovery

The current version of the data model directly embeds a verification key in the format of JWKS [[RFC7517]]. Effectively, the current model does not allow key rollover. Also, there is no key discovery mechanism yet, since keys are usually not difficult to retrieve for the Web Media use cases. At the same time, we assume the website is operated by the [=Originator=] itself, and is reliable enough.

Without a doubt, this is not always the case. Especially, if we extend the use of the [=Originator Profile Framework=] to other use cases, including the Web Advertisement, we need to have a better mechanism.

We are designing a key discovery and rollover scheme using DNS/DNSSEC. DNSSEC provides benefits, including but not limited to the following:

1. Allowing multiple keys for an identifier (such as DNS, Full Qualified Domain Name — FQDN) to coexist, with each key having different parameters, including validity period and algorithm selection.
2. Multiple signatures can be associated with a set of resource records, each of which can be linked to one of the currently published keys alongside its corresponding signature. This scheme allows for the simultaneous publication of both old keys and new keys for a specified period, facilitating a smooth key rollover.
3. Revoking a key is possible by just removing expired resource records.

While the current design of the [=Originator Profile Framework=] scheme does not rely on X.509[[X509V3]]-based certificates, it is possible to embed an X.509 certificate within the [=Core Profile=], then annotate it with multiple [=Profile Annotations=]. Unfortunately, if an X.509 certificate is used, it not only complicates the key rollover process, but also misses the benefits of DNSSEC, especially the low-overhead revocation. Note that the latest trend in operating X.509 certificates to address revocation checks is reducing the validity period, which is not ideal for our use case.

Profile Delivery/Retrieval

Currently, [=Originator Profile=] consists of [=Core Profile=], [=Profile Annotation=], [=Web Media Profile=], [=Website Profile=], and the [=Originator Profile=] is delivered via a well-known URL of the website. Each component of the [=Originator Profile=] may be distributed via different channels, then combined to be used at the [=Recipient=] side.

[=Core Profile=] is designed to be compact and deliverable via DNS, which relates to the aforementioned key rollover design. [=Profile Annotations=] may be delivered via different channels.

Extension of Profile Annotation

One of the key features of the [=Originator Profile Framework=] is its extensibility, which is achieved through the use of [=Profile Annotations=]. Each [=Profile Annotation=] can be defined to accommodate specific use cases and requirements, allowing for a flexible and adaptable framework. The following are some potential uses of the [=Profile Annotation=].