Mission Cross-Domain Projection for OAuth 2.0

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 8 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The issuance profile [I-D.draft-mcguinness-oauth-mission] makes a Mission a durable, human-approved, integrity-bound OAuth authorization artifact: one Authorization Server, the Mission Issuer, approves it, records it, and derives every token under it. That profile is deliberately single-domain: the AS that holds the Mission is the AS that issues for it.¶

Real tasks cross trust domains. An agent reconciling invoices may need a partner's ERP, behind a partner Authorization Server the home AS does not control and whose accounts it does not manage. This document specifies cross-domain projection: the originating Mission Issuer projects a Mission's authority, audience-scoped and integrity-anchored, to an Authorization Server in another trust domain, which honors it by minting local tokens for its own resources. The projection is a single hop, issuer to Resource AS; chaining a Mission across more than one trust-domain boundary remains future work ([I-D.draft-mcguinness-oauth-mission], Section "Non-Goals").¶

Two roles carry the model. The Mission Issuer (the Mission's issuer) remains the only party that creates, holds, and gates the Mission. A Resource AS honors a Mission it did not issue: it validates the projected grant, applies its own local policy, and mints its own tokens, preserving the Mission binding unchanged. A Resource AS is never the Mission Issuer.¶

2. Status: An OPTIONAL Extension

This document is the Cross-Domain capability named by the base profile's conformance model ([I-D.draft-mcguinness-oauth-mission], Section "Conformance"). The capability is OPTIONAL: a deployment whose Missions never leave their issuing AS does not implement this document, and the base profile is complete without it.¶

Two external dependencies set its deployment posture. The OAuth identity chaining architecture [I-D.draft-ietf-oauth-identity-chaining] is approved for publication and in the RFC Editor queue; the Identity Assertion Authorization Grant [I-D.draft-ietf-oauth-identity-assertion-authz-grant] is a working-group document. This document profiles them and cannot advance ahead of them; confining them here keeps the base profile free of in-progress cross-domain dependencies.¶

3. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses the terms of the base profile [I-D.draft-mcguinness-oauth-mission]: Mission, Mission Issuer (the Mission's issuer), Mission Intent, Authority Set, Subject, mission claim, derived token, derivation, the subset rule, and lifecycle gating. Authority Set entries are [RFC9396] authorization_details objects. All JSON shown in this document is non-normative and illustrative; the member definitions in the surrounding text are authoritative.¶

Resource AS:

An Authorization Server in another trust domain that honors a Mission it did not issue, minting its own tokens for its resources from a cross-domain grant. A Resource AS is never the Mission Issuer.¶

Cross-domain grant:

The short-lived JWT authorization grant the Mission Issuer issues toward a Resource AS (Section 6), carrying audience-scoped Mission authority and the mission claim. It is a Mission-bound token in the sense of the base profile.¶

Local token:

An access token a Resource AS mints for its own resources from a cross-domain grant (Section 7).¶

4. Cross-Domain Projection

A Mission is approved and held by one Mission Issuer (its issuer). This document lets a single Mission be honored by Authorization Servers in other trust domains, so a Mission can span more than one AS, using the cross-domain authorization grant of the OAuth identity chaining architecture [I-D.draft-ietf-oauth-identity-chaining]: the issuer AS issues, through an [RFC8693] token exchange, a short-lived JWT authorization grant audienced to the target Authorization Server, which the client redeems there with the [RFC7523] JWT-bearer grant.¶

This document calls that artifact the cross-domain grant and attaches Mission context to it (Section 6). The Identity Assertion Authorization Grant (ID-JAG) [I-D.draft-ietf-oauth-identity-assertion-authz-grant] is the RECOMMENDED profile of the cross-domain grant, and every example in this document uses it; another identity-chaining JWT authorization grant profile that meets the requirements of Section 6 MAY be used instead. Where a requirement elsewhere in this document names the ID-JAG, it is illustrating with the recommended profile and applies equally to any conforming cross-domain grant.¶

This document is a thin Mission-bound profile of the cross-domain grant, not merely mission-claim carriage: beyond attaching and validating Mission context, it imposes two security requirements on the grant for Mission-bound use, proof-of-possession and single use (Section 6, Section 7). The grant's own format, signing, and token-exchange envelope remain defined by the cross-domain grant profile (ID-JAG in the recommended case) and its underlying [RFC8693] and [RFC7523]; this document does not redefine them. The two added requirements are a floor: the cross-domain grant is the highest-authority credential crossing a trust boundary, and its profile does not by itself guarantee them.¶

In this model there is exactly one Mission Issuer per Mission (the issuer) and one or more Resource ASes in other domains that mint their own tokens for their resources. A Resource AS is never the Mission Issuer and MUST NOT create or alter a Mission.¶

5. Audience-Scoped Authority

When projecting authority toward a Resource AS, the Mission Issuer includes only the Authority Set entries whose resource that Resource AS is authoritative for, under the deployment's resource-to-AS mapping. Entries for other Resource ASes MUST NOT be disclosed.¶

6. Issuing the Cross-Domain Grant

Issuing a cross-domain grant is a derivation event and is gated like any other derivation ([I-D.draft-mcguinness-oauth-mission], Section "Mission Lifecycle and Gating"). A Mission-bound cross-domain grant:¶

• MUST be a JWT authorization grant issued and signed by the Mission issuer, redeemable at the target Resource AS through the [RFC7523] JWT-bearer grant;¶

• MUST be audienced to the target Resource AS, and MUST NOT have a lifetime exceeding 300 seconds (a short lifetime bounds cross-domain revocation latency; see Section 9.1);¶

• MUST have an exp that does not exceed the Mission's expires_at, per the base profile's expiry rule ([I-D.draft-mcguinness-oauth-mission], Section "Mission-Bound Access Tokens");¶

• MUST be sender-constrained ([RFC7800]) to the presenting client by the proof-of-possession mechanism the cross-domain grant profile defines, where it defines one. This document does not define a new PoP mechanism; the originating AS and the Resource AS MUST use the mechanism of the profile in use, so that binding and verification interoperate. When the grant profile in use defines no proof-of-possession, as the ID-JAG profile does not (the ID-JAG is a bearer authorization grant, protected by audience restriction, short lifetime, and client authentication at redemption), the grant carries a cnf claim ([RFC7800]) binding the presenting client's DPoP key (jkt, [RFC9449]) or mTLS certificate (x5t#S256, [RFC8705]), and the Resource AS MUST verify possession at redemption (Section 7). Binding and verification MUST use the same mechanism;¶

• MUST carry a jti for one-time use, so the bound party cannot replay it within its lifetime (Section 7, [RFC7523] Section 3);¶

• MUST carry the mission claim ([I-D.draft-mcguinness-oauth-mission], Section "The Mission Claim") with id, issuer, and authority_hash unchanged from the Mission, and the audience-scoped authorization_details (Section 5); and¶

• MUST convey the Mission's Subject in the form the identity chaining architecture defines, so the Resource AS can resolve it locally (Section 7).¶

The ID-JAG profile meets these requirements and is RECOMMENDED; in it the artifact is the ID-JAG and the issuance request carries a requested_token_type of urn:ietf:params:oauth:token-type:id-jag.¶

The client obtains the grant with an [RFC8693] token exchange. The subject_token MUST be the Mission's refresh token, with subject_token_type of urn:ietf:params:oauth:token-type:refresh_token, and the audience identifies the target Resource AS. The refresh-token subject is this profile's deviation from the ID-JAG issuance request, which that specification defines over an identity-assertion subject_token (id_token or saml2); a Mission-bound deployment substitutes the Mission's grant so the exchange resolves a Mission rather than a bare subject assertion. This refresh-token mode is what binds the request to a Mission: the AS resolves the Mission from the presented grant per the base profile's grant binding ([I-D.draft-mcguinness-oauth-mission], Section "Binding the Mission to the Grant"), exactly as on any other refresh, and the grant therefore projects the agent's full Mission authority (audience-scoped), never a narrowed delegate's.¶

This profile intentionally fixes the refresh-token subject mode to remove any ambiguity about which Mission authority a cross-domain grant projects: the refresh token resolves to exactly one Mission and its full authority, whereas an access token or delegated token could carry a narrowed or actor-specific subset. The cost is that this optional cross-domain binding is unavailable to a deployment that issues no refresh token; such a deployment uses the single-domain base profile, which needs no refresh token.¶

The AS MUST reject an access token or a delegated token presented as subject_token for cross-domain issuance. The AS MUST NOT resolve the Mission from a client-supplied mission_id, nor from an identity assertion that carries no Mission binding.¶

Before issuing, the AS MUST verify the Mission is active (failing otherwise with invalid_grant) and that the target Resource AS is authorized for the requested resources under the Mission's Authority Set (failing otherwise with invalid_target, [RFC8693]). The token-exchange response carries issued_token_type of urn:ietf:params:oauth:token-type:id-jag (for the RECOMMENDED profile) and token_type of N_A, per [RFC8693] Section 2.2.1.¶

This profile defines only the refresh-token subject_token mode above. Other Mission-bound subject-token modes, such as an access-token subject mode (which would have to bound the projected authority by the presenting token rather than by the full Mission Authority Set), are left to future profiles. Excluding the access-token subject mode here is a deliberate choice: it avoids propagating a narrowed or delegated authority across a trust boundary, where it could be re-widened. A deployment that does not issue the agent a Mission refresh token therefore cannot use this OPTIONAL cross-domain hop as defined here.¶

A delegate, rather than the agent, crossing a trust domain directly and carrying its own narrowed authority into another domain is out of scope for this document and deferred to future work. Cross-domain issuance here always projects the agent's Mission authority; delegation within the target domain is performed by the Resource AS (Section 7). A sub-agent that must act in a different trust domain under its own narrowed authority is therefore not covered by a single hop; distributed multi-agent work across domains composes only through the agent's projected authority or through separate Missions per domain. A delegate-carries-its-own-authority mode is future work.¶

Two roles MUST NOT be conflated. The grant the client presents to obtain the cross-domain grant (the Mission's refresh token) is the input to the exchange and selects the Mission; the Mission-bound access token plays no part here. The identity the issued grant conveys to the Resource AS is the Mission's Subject, which the AS populates from the Mission's recorded subject and which the Resource AS resolves locally per the identity chaining rules (this document defines no cross-domain subject mapping, Section 7).¶

Sender-constraining is REQUIRED for the cross-domain grant, stronger than the RECOMMENDED level the base profile sets for the primary access token ([I-D.draft-mcguinness-oauth-mission], Section "Mission-Bound Access Tokens"): it is the highest-authority credential in the chain and the only one that crosses a trust boundary, and the underlying grant provides no replay backstop of its own.¶

7. Validation at the Resource AS

A Resource AS consuming a Mission-bound cross-domain grant:¶

• MUST establish issuer trust in the originating AS by local policy or issuer metadata before accepting any Mission reference. It MUST NOT trust a mission.issuer merely because it appears inside a signed assertion.¶

• MUST validate the grant's signature and expiry, and verify its aud is the Resource AS's own identifier, rejecting a grant minted for a different Resource AS.¶

• MUST verify the grant's sender-constraint by the proof-of-possession mechanism the cross-domain grant profile defines (for the ID-JAG profile, as that specification defines), and MUST reject with invalid_grant a cross-domain grant that is not sender-constrained or whose proof-of-possession does not verify. When the grant profile defines no proof-of-possession and the grant carries a cnf claim per Section 6, the Resource AS MUST verify possession of that key at redemption: a DPoP proof ([RFC9449]) for its own token endpoint for a jkt binding, or the mTLS connection certificate ([RFC8705]) for an x5t#S256 binding. Binding and verification MUST use the same mechanism. A bearer grant MUST NOT be accepted: it is the highest-authority credential crossing the trust boundary, so accepting one unbound would let any party that captured it mint a local token.¶

  • Because this document defines no cross-domain status query, freshness is the Resource AS's only check that the Mission was active at issuance; the short grant lifetime bounds the staleness.¶

• MUST reject a replayed cross-domain grant: it MUST track the grant's jti for the grant's validity window and refuse a second presentation with invalid_grant ([RFC7523] Section 3), so a grant cannot be replayed even by the party it is bound to.¶

• When issuing local access tokens for its resources, the Resource AS uses the subject-resolution rules of the underlying cross-domain grant and identity chaining specifications. The local token preserves the mission claim (id, issuer, and authority_hash) unchanged from the cross-domain grant. The issuing iss is the Resource AS; mission.issuer remains the originating AS. Such a local token:¶

  • has an exp that MUST NOT exceed the grant's exp. The Resource AS does not hold the Mission's expires_at; because the grant's own exp is bounded by it (Section 6), the local token is bounded transitively;¶

  • MUST be sender-constrained ([RFC7800]), like the grant it derives from, and MUST NOT be issued as a bearer token; and¶

  • if it preserves the issuer's client_id, does so only as an audit reference, not a local identity: that value is in the originating AS's namespace, and a partner Resource Server MUST NOT resolve or authorize on it as a local client, for the same portability reason that applies to a sub matcher in allowed_delegates (see below).¶

• MUST bound the issued authorization_details by what the cross-domain grant conveyed, and MUST apply its own local authorization policy in addition: honoring a Mission does not obligate it to authorize any particular request. Because the conveyed entries were derived under the originating AS's local policy, the Resource AS does not re-derive them; it interprets and enforces them by their structure and vocabulary. It MUST fail closed on a conveyed actions identifier or constraints key it does not recognize for the resource in question, exactly as a Resource Server does ([I-D.draft-mcguinness-oauth-mission], Section "Resource Server Enforcement"), so authority it cannot interpret is never honored across the trust boundary rather than enforced by guess.¶

• MUST, when it issues delegated tokens of its own, enforce each entry's delegation policy as the base profile specifies ([I-D.draft-mcguinness-oauth-mission], Section "Delegation Constraints"); the policy travels on the conveyed entries. The cross-domain grant carries no act chain (Section 6), so the Resource AS's own delegation depth begins at 0.¶

A { "sub": ... } matcher in a conveyed entry's delegation.allowed_delegates is a client identifier in the originating AS's namespace and is not portable across the trust domain. When a Resource AS evaluates a conveyed entry, it MUST fail closed, narrowing the entry out, for any sub matcher it cannot resolve against the delegate it authenticated in its own namespace. Portable cross-domain matching SHOULD therefore use a sub_profile matcher, an actor-type class rather than a domain-relative identifier ([I-D.draft-mcguinness-oauth-mission], Section "Delegation Constraints").¶

This document does not define cross-domain subject mapping. A Resource AS consuming a Mission-bound cross-domain grant resolves the subject of any local token according to the cross-domain grant profile in use (the Identity Assertion Authorization Grant profile in the recommended case), the OAuth identity chaining architecture, and its local trust and account-linking policy. This document only requires that the Mission binding (mission.id, mission.issuer, and authority_hash) and the audience-scoped authorization_details remain bounded as described here.¶

Downstream, authority_hash is an immutable audit and correlation anchor to the originating AS's consent commitment. A Resource AS and its Resource Servers hold only the audience-scoped subset, never the full Authority Set, so they cannot recompute authority_hash ([I-D.draft-mcguinness-oauth-mission], Section "Integrity Anchors"); its integrity rests on the signature chain (the originating AS signs the ID-JAG; the Resource AS validates issuer trust and signs its local token). It is verifiable only against the originating AS, which this document does not require to be exposed.¶

8. Introspection at a Resource AS

The base profile's OPTIONAL token introspection ([RFC7662]) reports a mission response member, and only the Mission issuer reports the Mission's lifecycle state ([I-D.draft-mcguinness-oauth-mission], Section "Mission State via Token Introspection"). This section specifies the non-issuer half of that rule.¶

A Resource AS that supports introspection for a local token it minted from a cross-domain grant returns the claim-shape members only: id, issuer, and authority_hash. It holds the token, not the Mission: it knows the Mission state only as of grant validation and has no query to the issuer keyed by mission_id (neither this document nor the base profile defines one). It MUST omit mission.state rather than report a stale value as current. authority_hash, when included, is the issuer's commitment carried through the grant, not a value the Resource AS recomputes from its audience-scoped subset ([I-D.draft-mcguinness-oauth-mission], Section "Consent Binding").¶

9. Security Considerations

The security considerations of the base profile [I-D.draft-mcguinness-oauth-mission] and of the identity chaining architecture [I-D.draft-ietf-oauth-identity-chaining] apply.¶

10. Privacy Considerations

The cross-domain grant and every local token minted from it carry the canonical mission_id, mission.issuer, and authority_hash unchanged, so a Resource AS and its Resource Servers can correlate a Mission's activity across domains, and mission.issuer identifies the issuing AS to the partner domain. This is the deliberate correlation property of the base profile ([I-D.draft-mcguinness-oauth-mission], Section "Mission Identifier Correlation"), extended across the trust boundary. Audience scoping (Section 5) is the minimization measure: a Resource AS never sees Authority Set entries addressed to other audiences.¶

11. Conformance

An implementation conforms in one of two roles.¶

An Originating Mission Issuer with Cross-Domain is a conforming Mission Issuer of the base profile ([I-D.draft-mcguinness-oauth-mission], Section "Conformance") that additionally issues the Mission-bound cross-domain grant per Section 6, including the audience scoping of Section 5.¶

A Resource AS honors the cross-domain grant per Section 7 and, where it offers token introspection for its local tokens, follows Section 8. A Resource AS is not required to implement the base profile's Mission Issuer role; it never creates or alters a Mission (Section 4).¶

12. IANA Considerations

This document has no IANA actions. The mission JWT claim, the mission introspection response member, and the mission_resource_access authorization details type it carries are registered by the base profile [I-D.draft-mcguinness-oauth-mission].¶

13. References

Appendix A. End-to-End Example (Non-Normative)

This appendix continues the end-to-end example of the base profile's appendix across a trust boundary: from the home domain (as.example.com) into a partner domain, and then into the partner's internal microservice call chain. It is illustrative and adds no normative requirements. The final intra-domain hop shows one deployment-local way to carry Mission context in a Transaction Token [I-D.draft-ietf-oauth-transaction-tokens]. Identifiers and hash values are illustrative and are not computed from the displayed JSON.¶

The chain crosses boundaries in two distinct ways, and seeing why is the point of the example:¶

• The Identity Assertion Authorization Grant (ID-JAG) crosses between trust domains: from the home domain (as.example.com) to the partner domain (ras.partner.example.com).¶

• Transaction Tokens propagate within the partner trust domain: from the partner's Resource Server through its internal services.¶

The Mission is the durable anchor across both: mission.id, mission.issuer, and authority_hash ride unchanged through every hop. OAuth authority is audience-scoped by the Mission Issuer and Resource AS; deployment-local transaction context then narrows the operation for internal services. In this baseline walkthrough no hop calls back to mission.issuer for state; each enforces from the credential it holds. The OPTIONAL companion profiles layer on this baseline, and the stages note where: Stage 4 gains a runtime point-of-use check, and Stage 3 gains prompt cross-domain revocation from Status or Signals.¶

Scenario: agent s6BhdRkqt3, acting for alice (user_3p2q8mN1a0kV7tR), reconciles Q3 invoices in a partner ERP under Mission msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-. Stage 0 (agent identity) and Stage 1 (Mission creation at the home AS) are the base profile's single-domain walkthrough, extended here in one way: the Mission Intent's resources also names the partner ERP https://erp.partner.example.com, so the approved Authority Set additionally carries, for that resource, an invoices.read entry (delegable to ai_agent actors at depth 1) and a journal-entries.write entry capped at a max_amount of 500.00 USD. The Mission was recorded active with authority_hash sha-256:Gv2nD9bM7sX1cF8gH0pVl3KvZ4mP5x0wQrR6tY2jE5kQ and intent_hash sha-256:Zb8mR3nX5pV4lE6sQqYwQ7p4LHnX9Md0LqJ6sZJ2xT5f (illustrative; this Mission's Intent and Authority Set extend the single-domain walkthrough's, so its anchors differ from that example's). The partner ERP is behind the Resource AS ras.partner.example.com, so the agent's next step is a cross-domain projection rather than a home-domain access token.¶

{
  "iss": "https://as.example.com",
  "aud": "https://ras.partner.example.com",
  "sub": "user_3p2q8mN1a0kV7tR",
  "client_id": "s6BhdRkqt3",
  "iat": 1793606400,
  "exp": 1793606700,
  "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" },
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://erp.partner.example.com",
      "actions": ["invoices.read"],
      "delegation": {
        "max_depth": 1,
        "allowed_delegates": [{ "sub_profile": "ai_agent" }]
      } },
    { "type": "mission_resource_access",
      "resource": "https://erp.partner.example.com",
      "actions": ["journal-entries.write"],
      "constraints": { "max_amount":
        { "amount": "500.00", "currency": "USD" } } }
  ],
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:Gv2nD9bM7sX1cF8gH0pVl3KvZ4mP5x0wQrR6tY2jE5kQ"
  }
}

{
  "iss": "https://ras.partner.example.com",
  "aud": "https://erp.partner.example.com",
  "sub": "partner-user_7Kp4QnZ2vR9s",
  "client_id": "s6BhdRkqt3",
  "iat": 1793606430,
  "exp": 1793606690,
  "jti": "at_7Kp4QnZ2vR9sT1mX8b3N",
  "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" },
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://erp.partner.example.com",
      "actions": ["invoices.read"],
      "delegation": {
        "max_depth": 1,
        "allowed_delegates": [{ "sub_profile": "ai_agent" }]
      } },
    { "type": "mission_resource_access",
      "resource": "https://erp.partner.example.com",
      "actions": ["journal-entries.write"],
      "constraints": { "max_amount":
        { "amount": "500.00", "currency": "USD" } } }
  ],
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:Gv2nD9bM7sX1cF8gH0pVl3KvZ4mP5x0wQrR6tY2jE5kQ"
  }
}

{
  "iss": "https://txn.partner.example.com",
  "aud": "https://ledger.partner.example.com",
  "sub": "partner-user_7Kp4QnZ2vR9s",
  "tid": "txn_5kQ9pX2vN7sR1tY8mZ3",
  "iat": 1793606460,
  "exp": 1793606520,
  "txn_authorization": {
    "source_resource": "https://erp.partner.example.com",
    "source_actions": ["invoices.read"],
    "internal_operation": "ledger.lookup_invoice",
    "constraints": { "invoice_id": "inv_2026Q3_1042" }
  },
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:Gv2nD9bM7sX1cF8gH0pVl3KvZ4mP5x0wQrR6tY2jE5kQ"
  }
}

Author's Address