Huawei

wangdonghui124@huawei.com

Huawei

liufei19@huawei.com

Huawei

lilun20@huawei.com

Security Secure Patterns for Internet CrEdentials public key service SPICE provides a selective disclosure mechanism of credentials from issuer. However, future network services may be built on the trust between multiple entities. Obtaining the public key of multiple issuers for a verifer from potential multiple sources can be complex. In this contribution, an optional public key service is proposed in SPICE architecture for the issue of obtaining the public keys of the issuers from multiple trusted entities. The basic function of public key service is proposed including public key registration, token verification, and a potential implementation such as the distributed ledger. We hope that the proposed contribution can be used as infomative for SPICE regarding to the token validation procedure.

With the development of Web3.0, the future society and network will become more people-oriented and facilitate more cross-field collaboration. In this context, there will be a greater need for the establishment of cross-field trust, which means a credential issued by one issuer may be verified by multiple verifiers. Or a verifier may need to verify credentials issued by multiple issuers. As a result, it requires trust be established between each pair of issuers and verifiers before the verification. For example, in the express-telecom integration scenario, a courier with an express company-issued staff credential makes calls via the telecom operator's network. To help the recipient confirm the caller's identity and avoid rejecting it as a nuisance call, the courier submits the credential to the telecom operator, which then verifies it. Only after successful verification will the call display show it's a legitimate courier call. In this scenario, for telecom operators, they need to be able to verify the credentials of multiple express delivery companies. Conversely, for express delivery companies, their credentials need to be verifiable by multiple operators. Furthermore, as more participants join, such as express goods manufacturers, the verification relationships will become more complex. Express delivery companies then need to build equally complex trust relationships with them, and so on. Therefore, the future trust establishing is no longer a simple one-to-one or one-to-many relationship. Instead, it forms a complex network of trust relationships. During the verification, the verifiers need to obtain the isser's public key to verify the token such as RFC 9207 and RFC 9449 , or the selective disclosed token such as SD-CWT() . But future complex verification relationship makes the obtaining of issuer public keys more difficult than ever before. Different issuers may adopt different public key disclosure mechanisms. This requires verifiers to have the ability to get the public key one by one, also deal with the security risks during the transmission and storage. Otherwise, it may lead to errors in credential verification and trigger business risks. Based on the above requirements, this document presents a new entity called Public-Key-Service-Provider(PSKP) for public key issues in SD-CWT verification to provide public key registration, and querying. To ensure its efficient, stable, and secure operation, the PSKP has these features: distributed deployment to prevent single-point failure, non-tamperability for data integrity, and consensus-based data writing for consistency.

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 .

As shown in Figure 1, PKSP plays a crucial role in the public key registration and verification process. As a public public key service platform, PKSP accepts public key registration from issuers, stores the registered public keys securely and in a non-tamperable manner. When a verifier queries for a key, it provides the corresponding public key. Besides, with the transformation of participants' roles, for example, participant A holds a credential issued by Participant B and also acts as an issuer to issue a credential to Participant C. In this case, A can also register its public key on the platform as an issuer.

| Verifier | | | +----------+ Figure 1 System architecture of a Public-Key-Service-Provider]]>

As for the implementation technology of PKSP, distributed ledger technology strongly enables PKSP to meet these features. Decentralized storage spreads data across multiple nodes to prevent single-point failures. The tamper-proof data structure, formed by complex encryption, makes data modification extremely hard. Besides, the consistency maintenance based on multi - party consensus, such as the Practical Byzantine Fault Tolerance (PBFT) algorithm, ensures that multiple nodes conduct verification for public key operations in the PKSP. Only when most nodes approve are operations recorded, reducing the impact of malicious or wrong actions by individual nodes.

It enables legitimate issuers to register their public key information into the public key service. During the registration process, identity verification is usually carried out to ensure that only legitimate entities can add public keys. The service conducts preliminary checks on the format and validity of the public key to ensure it meets the system requirements. In a distributed ledger, the function of public key registration can be implemented through smart contracts. The registration process between the issuer and the PKSP is as follows: 1. Submission by the Issuer. The issuer initiates registration by sending a request to the PKSP. This request contains the issuer's public keys. Meanwhile, the issuer declares the purposes of these keys, such as for token issuance, revocation, and so on. Along with the public keys, detailed descriptive information about the issuer is provided. This includes the issuer's name, identifier, the expiration time of the public keys, as well as a declaration of the claims of the tokens the issuer can provide. 2. Validation by the PKSP. Upon receiving the registration request, the PKSP first validates issuer's public key. The descriptive information provided by the issuer is then carefully examined for accuracy and completeness. The PKSP may cross-reference this information with existing databases or industry-recognized sources to verify the issuer's legitimacy. 3. Response from the PKSP. If all the information is found to be valid and compliant, the PKSP sends a registration response to the issuer. This response includes a confirmation of successful registration. The PKSP may also provide additional information like the storage location of the issuer's public key within the PKSP. In case the registration request is not approved, the PKSP sends a rejection notice to the issuer, stating the reasons for rejection. 4. Completion of Registration. Once the issuer receives a positive response from the PKSP, the registration process is considered complete. The issuer can then start using the registered public key for its intended purposes and issue tokens according to the specifications provided during registration. The PKSP updates its records to reflect the newly registered issuer and is ready to support the verifiers in matters related to public key querying.

When a verifier is performing SD-CWT verification, it can query the public key information of relevant issuers through the PKSP. It supports various query methods, such as precise queries based on the identity identifier of the entity, certificate number, etc., to quickly obtain the required public key. The following steps shall be performed between verifiers and PKSP: 1. Token Receipt. The Holder sends the token containing relevant information to the Verifier. 2. Request for Public Key from PKSP. After receiving the token, the Verifier extracts the identification information of the issuer from the token. For example, the "iss" field in the header or payload may be found to identify the issuer. The Verifier then uses this identification information to send a request to the PKSP, asking for the public key corresponding to this issuer. 3. PKSP Processes the Request and Returns the Public Key. When the PKSP receives the verifier's request, it first authenticates the verifier's identity. After successful authentication, based on the issuer identification provided in the request, it searches for the corresponding public key in its storage system. Then the PKSP returns this public key to the verifier as a response message. The response message may also contain some metadata, such as the expiration date of the public key and the type of the public key. 4. Token Verification. The Verifier uses the public key obtained from the PKSP to verify the token according to the signature algorithm specified in the token. 5. Processing of Verification Results If the verification passes, the verifier can perform subsequent business logic processing based on the information in the token payload, such as allowing the holder to access specific resources. If the verification fails, the verifier usually rejects the operations related to this token and may record relevant log information for subsequent security audits and problem-troubleshooting.

As a distributed ledger-based service, the PKSP is well-served by choosing a permissioned ledger when considering efficiency and security. The permissioned ledger aligns with PKSP requirements in multiple ways: Efficiency: In contrast to public distributed ledger, the number of nodes in a permissioned ledger is more manageable, and all participating nodes are pre-authorized. This streamlines the consensus process. With fewer nodes to coordinate, the time to reach consensus is shortened, thereby enhancing PKS's business - handling speed. For instance, in identity verification, public key verification can be expedited, minimizing user waiting time. Security: The permissioned ledger features a stringent access mechanism. Only authorized nodes can be part of it, reducing the vulnerability to external malicious attacks. Moreover, due to their common origin in a specific cooperation system, nodes in the permissioned ledger have a high level of mutual trust. They share a common interest in safeguarding data security and platform stability. This trust bolsters data security and integrity, preventing illegal data tampering and meeting PKSP's data tamper-resistance demands.

In the context of modern digital infrastructure development, the establishment of a reliable PKSP ledger infrastructure is of utmost importance. As we delve into the options for constructing this critical infrastructure, operators stand out as highly suitable candidates. The distributed ledger of PKSP can be built either by Issuers with network infrastructure capabilities or based on the existing 5G communication network infrastructure, mainly due to the following key factors: 1. Network Foundation and User Identity Management Advantages: The telecommunications network serves as the cornerstone of global interconnection, shouldering the responsibility of serving billions of users worldwide. During long - term operations, the telecommunications network is deeply involved in user identity management. As an indispensable part of identity attributes, user tokens can be naturally and tightly bound to user identities. This natural connection endows the construction of the PKSP ledger infrastructure based on the telecommunications network with unique advantages. It can effectively integrate user identity verification and token management processes, enhancing overall security and convenience. 2. Trustworthiness Assurance: Operators have accumulated extensive social trust during their long - term operations and are highly trustworthy organizations. Relying on this advantage, operators can provide users with verifiable tokens, ensuring the credibility and reliability of tokens in various business scenarios. This not only helps to enhance users' trust in their own digital identities but also provides a solid trust foundation for the expansion of token - based businesses. 3. Broad Cooperative Potential: Operators possess strong cooperation and expansion capabilities and can carry out in - depth cooperation with non - operator institutions such as OTT manufacturers, authoritative organizations, and social third - parties. Through this cross - field cooperation model, a more abundant and diverse digital identity verification and management ecosystem can be constructed for the whole society. It gives full play to the advantages of all parties, realizes resource sharing and complementarity, and further expands the coverage and application value of the PKSP ledger infrastructure.

IANA Considerations This document has no IANA considerations.

TODO

This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. This document specifies a new parameter called iss. This parameter is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. The iss parameter serves as an effective countermeasure to "mix-up attacks". 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.

Acknowledgments TODO