<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="exp" docName="draft-song-spice-telecom-usecases-00"
     ipr="trust200902">
  <front>
    <title abbrev="Abbreviated-Title">SPICE Use Cases in Telecom
    Network</title>

    <author fullname="Yurong Song " initials="Y" surname="Song">
      <organization>Huawei</organization>

      <address>
        <email>songyurong1@huawei.com</email>
      </address>
    </author>

    <author fullname="Lun Li" initials="L." surname="Li">
      <organization>Huawei</organization>

      <address>
        <email>lilun20@huawei.com</email>
      </address>
    </author>

    <author fullname="Donghui Wang" initials="D" surname="Wang">
      <organization>Huawei</organization>

      <address>
        <email>wangdonghui124@huawei.com</email>
      </address>
    </author>

    <author fullname="Fei Liu" initials="F." surname="Liu">
      <organization>Huawei</organization>

      <address>
        <email>liufei19@huawei.com</email>
      </address>
    </author>

    <date day="3" month="March" year="2025"/>

    <area>Security</area>

    <workgroup>Secure Patterns for Internet CrEdentials</workgroup>

    <keyword>SPICE</keyword>

    <abstract>
      <t>This document describes use cases of the credential specific to the
      telecom network. It aims to propose benefits and scenarios regarding to
      introducing the credential to the telecom network, which can provide
      more scenarios and directions to Secure Patterns for Internet
      CrEdentials (SPICE) specifications.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>The future telecom network will be user-centric, with rich
      application scenarios, and more consideration of user requirements. For
      example, users may need to apply and present proof of attributes to get
      services from operators or other organizations, thus telecom network
      needs to support issuance, storage and verification of proof of
      attributes. Verifiable credentials have flexible templates of claims,
      and are able to implement verification on demand, which can bring many
      benefits to the future network. This document will describe the use
      cases of credential in two aspects: for users of the telecom network,
      the credentials can introduce the concept of attribute to the network,
      and enable derivation of temporal subscriptions; for network entities,
      such as network functions (NFs) or base stations, credentials can not
      only facilitate cross-domain authentication, but also be used to
      precisely describe the functionalities of these network entities.</t>
    </section>

    <section title="Use Cases">
      <t>This document makes no request of IANA.</t>

      <section title="Telecom User Credentials">
        <section title="Notional Architecture of Using Credentials for Telecom User">
          <t>Traditionally after signing a contract with a telecom operator,
          the user will obtain a subscription identity and the corresponding
          symmetric key issued by the operator for the user and store this
          information inside the device (e.g. cell phone, SIM/eSIM), and the
          subscription information will be stored inside the operator's
          network. Then the user can access the operator's network and request
          services (e.g., making and receiving calls). The operator's network
          consists of access network (including base stations) and core
          network (including various Network Functions (NFs) that provide
          services such as access, authentication, and exposure). When the
          user's cell phone accesses the operator's network, the operator can
          retrieve the subscription information from core network and verify
          the user's identity based on it. The operator can also establish a
          connection with Over-The-Top (OTT) providers.</t>

          <t><figure>
              <artwork align="center"><![CDATA[
       User                           Operator             
+----------------+       +-------------+   +--------------+
|     Device     |       |   Access    |   | Core Network |
|                |       |   Network   |   | +-----+      |
|                |       | +---------+ |   | | NF1 |      |
| +------------+ |-------| |  Base   | |---| +-----+      |
| | credential | |       | | Station | |   | +-----+      |
| +------------+ |       | +---------+ |   | | NF2 |  ... |
|                |       |             |   | +-----+      |
+----------------+       +-------------+   +--------------+
      Holder                      Issuer/Verifeir
      
Figure 1: Notional architecture of using credentials for telecom user   ]]></artwork>
            </figure></t>

          <t>In this use case, the user is the holder of the Verifiable
          Credentials (VCs), while the operator or OTT providers can act as
          both the issuer and the verifier of the credentials. These
          credentials can be stored within the SIM/eSIM, taking advantage of
          its secure storage capabilities. Additionally, they may also be
          stored on the user's cell phone.</t>
        </section>

        <section title="Introduce Attributes into Telecom Network">
          <t>At present, when a user subscribes to a telecom operator, a
          subscription identifier is issued. This identifier is bound to the
          user's subscription information stored in the operator's core
          network, enabling the operator to identify the user. However, the
          current subscription information in the telecom network lacks the
          ability to describe the user's real-world natural attributes (e.g.
          job, age, degree).</t>

          <t>Looking ahead, there will be scenarios in which it is necessary
          to introduce attributes into the telecom network. For example,
          delivery workers can apply for verification of their job - related
          attributes and present the proof to the telecom operator. After
          successful verification, the operator can tag their calls.
          Consequently, customers can easily identify that the calls are from
          legitimate delivery workers rather than impostors.</t>

          <t>In such cases, it is beneficial to introduce VCs. Operators or
          OTT providers have the capability to issue VCs to users, which serve
          as reliable proofs of users' attributes. VCs issued by OTT providers
          can be verified by operators, and conversely, those issued by
          operators can be verified by OTT providers. This innovative approach
          simplifies users' daily lives significantly. Moreover, it has the
          potential to transform the operator's reputation into tangible
          commercial value, enabling a wider range of business scenarios and
          bringing numerous benefits to the network.</t>
        </section>

        <section title="Enable the User to Derive Temporal Subscription">
          <t>In the future, there will likely be scenarios where users need to
          obtain temporary subscription information which should grant access
          to the same or a reduced set of services compared with the original
          user's subscription. Consider the following cases: when a user's
          child participates in a one-week summer camp abroad or a friend is
          visiting for a short period but has difficulty making prior
          arrangements, the user might wish to utilize their own subscription
          to assist these individuals in obtaining a short-term subscription
          from the operator.</t>

          <t>Presently, the subscription information within the telecom
          network is static, and updating it is a cumbersome process. To meet
          the requirements of such temporary usage scenarios, users may need
          to request multiple SIM/eSIMs. Currently, the network allows users
          to either pre-sign a tariff contract with multiple lines or order
          multiple SIM/eSIM tariff plans with different identities and keys.
          However, these methods are not only cost-inefficient but also offer
          limited customization in terms of services. As the number of
          services for multiple devices continues to expand, it becomes
          increasingly complex for users to manage different identities and
          keys.</t>

          <t>The introduction of VCs into the telecom network can
          revolutionize the customization of users' subscription information
          and streamline identity and key management. Users can apply for
          temporary sub-VCs based on the VCs issued by the operator and
          distribute them to relatives, friends, or connected devices such as
          electronic watches, monitors, robots. Sub-VCs enable access to the
          telecom network with the equal or fewer permissions compared to the
          primary user. This approach endows users with enhanced flexibility
          and simplicity in managing their identities and keys, effectively
          resolving the issues associated with current subscription management
          methods.</t>
        </section>
      </section>

      <section title="Telecom Network Element Credentials">
        <section title="Notional Architecture of Using Credentials for Telecom Network Element">
          <t><figure>
              <artwork align="center"><![CDATA[   User                             Operator                    
+--------+       +--------------------+   +--------------------+
|        |       |       Access       |   |    Core Network    |
|        |       |       Network      |   |                    |
|        |       | +----------------+ |   | +----------------+ | 
|        |       | |      Base      | |   | |       NF       | |
| Device |-------| |     Station    | |---| | +------------+ | |
|        |       | | +------------+ | |   | | | credential | | |
|        |       | | | credential | | |   | | +------------+ | |
|        |       | | +------------+ | |   | +----------------+ |
|        |       | +----------------| |   |         ...        |
+--------+       +--------------------+   +--------------------+
 Verifier            Holder/Verifier      Issuer/Holder/Verifeir
      
Figure 2: Notional architecture of using credentials for telecom network element    ]]></artwork>
            </figure>In this use case, network entities such as base stations
          and NFs assume the role of credential holders. The operator
          typically functions as the issuer of these credentials. The
          verifiers can be either other network entities or user devices (e.g.
          cell phone, SIM/eSIM).</t>
        </section>

        <section title="Achieve Cross-Domain Authentication">
          <t>Currently within the telecom network, upon deployment, network
          elements such as NFs and base stations acquire certificates from the
          operator's Certificate Authority (CA). These certificates are
          typically based on the X.509 described in<xref target="RFC5280"> RFC
          5280</xref> format and contain the public keys of the NFs and base
          stations. Their verification is restricted to entities that have
          pre-installed the CA's public key. Moreover, the issuance, update,
          and revocation of these certificates are solely controlled by the
          CA.</t>

          <t>As the telecom industry continues to evolve, the network
          ecosystem is expected to involve multiple stakeholders. With the
          growing cooperation and interaction among multiple operators, and
          the emerging trend of inviting other organizations, such as
          manufacturers and OTT providers, to participate in network
          construction, the telecom network will support multi-party trust.
          Additionally, the continuous emergence of new application scenarios,
          such as smart city, and real-time augmented reality services across
          different regions, has led to need for dynamic network. In this
          scenario, network entities will likely face the urgent need for
          seamless authentication by entities in other network domains, and
          self-oriented management of identities and keys.</t>

          <t>The traditional certificate-based authentication model, which
          relies solely on the operator's CA, may not be sufficient to meet
          the requirements of this more complex and collaborative environment.
          The introduction of VCs offers a solution. These credentials can be
          issued by various trusted entities, including different operators
          and OTT providers, thus establishing trust across different network
          domains. Additionally, network entities can actively apply for VCs
          or trigger the update and revocation of VCs. This not only enables
          on-demand key rotation based on security requirements or changing
          network conditions but also aligns with the requirements of dynamic
          network construction.</t>
        </section>

        <section title="Provide Endorsement for Device Information">
          <t>The functionality of network entities is represented and stored
          in the telecom network in the form of static profiles. These
          profiles are established solely during the registration process and
          undergo minimal modification thereafter. For instance, an NF profile
          typically includes details such as the NF Type, Instance ID,
          supported Public Land Mobile Network (PLMN), capability information,
          and priority information.</t>

          <t>In the future, as the telecom network involving multiple
          operators and OTT providers in network construction, a network with
          multi-party trust will emerge. In such an environment, network
          entities may register across different network domains. For example,
          NFs may need to join the networks of other operators, and thus they
          need to provide their NF profiles and register with those receiving
          operators. Challenge occurs that the receiving operator requires a
          reliable method to determine the authenticity and trustworthiness of
          the provided NF profile.</t>

          <t>By using VCs to describe network entity information, the home
          operator or OTT of the network entity can provide an endorsement.
          Then, the receiving operators or OTTs in another network domain can
          verify the VC, ensuring that the network entity information
          described within it is accurate and legitimate. This not only
          ensures the security and trustworthiness of cross-domain
          interactions but also equips the network with the flexibility
          necessary to meet the dynamic requirements of the evolving telecom
          network ecosystem.</t>
        </section>
      </section>
    </section>

    <section title="Further work on telecom credentials">
      <t>The further work regarding the introduction of verifiable credentials
      may encompass the following aspects:</t>

      <t><list style="symbols">
          <t>Credential Generation and Storage Support: Network entities and
          mobile phones need to be enabled to support the generation and
          storage of verifiable credentials. This requires the implementation
          of appropriate software and hardware mechanisms within these devices
          to create, securely store, and manage the credentials.</t>

          <t>Authentication and Authorization Based on Credentials: Network
          entities and mobile phones should be able to achieve authentication
          and authorization processes using verifiable credentials. For
          example, during the connection of a mobile phone to a network
          entity, the phone can present its verifiable credential, and the
          network entity can authenticate the phone based on the credential's
          information and grant appropriate authorization for services.</t>

          <t>Privacy Protection through Selective Disclosure: The use of
          verifiable credentials should enable privacy protection through
          selective disclosure. Network entities and mobile phones should have
          the ability to disclose only the necessary information from the
          credentials as required by the specific context. For instance, in a
          certain service request, a mobile phone may only need to disclose
          its identity-related information from the credential, without
          revealing other sensitive details such as personal preferences or
          location history.</t>
        </list></t>
    </section>

    <section title="Security Considerations">
      <t>There is no security and privacy issues in this document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement
          Levels</title>

          <author fullname="S. Bradner" initials="S." surname="Bradner"/>

          <date month="March" year="1997"/>

          <abstract>
            <t>In many standards track documents several words are used to
            signify the requirements in the specification. These words are
            often capitalized. This document defines these words as they
            should be interpreted in IETF documents. This document specifies
            an Internet Best Current Practices for the Internet Community, and
            requests discussion and suggestions for improvements</t>
          </abstract>
        </front>

        <seriesInfo name="BCP" value="14"/>

        <seriesInfo name="RFC" value="2119"/>

        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>

      <?rfc ?>

      <reference anchor="RFC5280">
        <front>
          <title>Internet X.509 Public Key Infrastructure Certificate and
          Certificate Revocation List (CRL) Profile</title>

          <author fullname="D. Cooper" initials="D." surname="Cooper"/>

          <author fullname="S. Santesson" initials="S." surname="Santesson"/>

          <author fullname="S. Farrell" initials="S." surname="Farrell"/>

          <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>

          <author fullname="R. Housley" initials="R." surname="Housley"/>

          <author fullname="W. Polk" initials="W." surname="Polk"/>

          <date month="May" year="2008"/>

          <abstract>
            <t>This memo profiles the X.509 v3 certificate and X.509 v2
            certificate revocation list (CRL) for use in the Internet. An
            overview of this approach and model is provided as an
            introduction. The X.509 v3 certificate format is described in
            detail, with additional information regarding the format and
            semantics of Internet name forms. Standard certificate extensions
            are described and two Internet-specific extensions are defined. A
            set of required certificate extensions is specified. The X.509 v2
            CRL format is described in detail along with standard and
            Internet-specific extensions. An algorithm for X.509 certification
            path validation is described. An ASN.1 module and examples are
            provided in the appendices. [STANDARDS-TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="5280"/>

        <seriesInfo name="DOI" value="10.17487/RFC5280"/>
      </reference>
    </references>
  </back>
</rfc>
