Consider the use of short-term ("access_token") vs long-term ("refresh_token") PID credentials

[earizon]

Very briefly, the current ARF architecture considers the issuance of "long-term" PIDs. With the current cryptographic schemas used for signature and data obfuscation this leads to the privacy and linkability problems mentioned in this issue: https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/163

A "work around" is the emission of a PID credential that is stored on the wallet, but is never directly used as part of the presentation to relying parties but just as a "refresh token" (using OAuth nomenclature).

The wallet will use the original (long-term) PID only to request to the original PID issuer new short-term PIDs ("access_token" or "id_token" using the OAuth or OpenID nomenclature). Such short-term PIDs will be the ones presented to relying parties.

The wallet must have a notion of "pool" of short-term PIDs:

• The short-term PIDs will be "wasted", in general, once presented to relying parties.
• The wallet must "recharge" the "pool" when online by requesting new ones to the original PID issuer (independently or asynchronously to any future presentation).

When comparing the issuance effort:

• The long-term ("refresh token") PID will be "hard" and "slow" to issue, requiring onboarding security measures and maybe (probably) human procedures to ensure that the contained claims really reflect the real identity of the "targeted" subject as already reflected in the ARF. Pottentially An initial request will be made to initiate the issuance and later on the PID will be provided (asyncrhonously) to the wallet.
• The short-term ("access token") PIDs will be issued automatically (synchronously) by just presenting the long-term PID, unless the PID issuer has decided to revoke the PID.

Pros & Cons of using short-term PIDs:

• "PROs":
  • Simplified security: No need anymore for complex "revocation list" mechanisms, just blocking the issuance of new short-term PIDs will be enough. (This is how OAuth has been working for years, with no major issues detected).
    
  • New short-term PIDs can be issued with a restricted subset of information (age_over_18, ...).
  • The issuer can have updated information about the subject not present during the initial issuance of the original PID (age_over_18 has changed for example), so the sort-term PIDs will have updated information.
• "CONs":
  • PID issuer needs to issue potentially hundreds of short-term PIDs during the life-time of the long-term PID. It doesn't look to be really a big issue considering the current state of software and hardware stacks: C&P from https://blogs.oracle.com/developers/post/open-sourcing-jipher "(jipher) scaled across trillions of cryptographic operations every day"

NOTE: This same architecture can be used for any other long-term credential containing sensitive information.

[peppelinux]

Short-lived PIDs necessitate user consent and authentication, significantly impacting the user experience (UX). This because to request a new credential with loa high, eg: the PID, requires the user to be authenticated.

Other elements that may be of interest in this analysis are the following:

• In OAuth 2.0 the refresh token is used without any user control, since the token is owner by the RP and not by the User
• To store a PID/EAA to the secure storage, the user must be authenticated and give the consent, granting the write grants to the application

Side note about security: A stolen refresh token together with a brand new WIA would be enough to steal a brand new PID and this may represent an issue in consideration of the problem of adversaries like the rogue employee: a rogue employee could exploit a stolen refresh token in conjunction with a new Wallet Instance Assertion (WIA) to illicitly obtain a new Personal Identifier (PID). This vulnerability is particularly concerning because it could allow unauthorized access to sensitive systems or data without detection, leveraging legitimate authentication mechanisms in a malicious manner.

[earizon]

"Short-lived PIDs necessitate user consent and authentication, significantly impacting the user experience (UX). "

This makes no sense to me. The idea of the OAuth 2.0 refresh_token + access_token is to provide control TO THE ISSUER (the PID issuer in the ARF), not the user, to revoke the previously issued credential at will.

"To store a PID/EAA to the secure storage, the user must be authenticated and give the consent, granting the write grants to the application" Once the user has accepted the initial PID, It makes no sense to ask the user "again and again" to accept "clones" (or subset) of the first one. We sign with a company for a new supply contract, then we do not periodically consent to receive new bills.

The claims about security also is plain wrong. Once a long-term PID is stolen, the issuer has to revoke it. In the current scenario, the issuer must update the revocation list, the revocation list must be published "somewhere", relaying parties must periodically update the revocation list and check against such list for every new verification. At each point, a hacker can compromise the system. Alternatively, with the "refresh token" approach, the issuer does not issue any new short-live token once the the PID has been compromised. Once the last short-live token has expired, it becomes useless. Fewer attack points means more security "for free".

edit: The revocation list mechanism can coexists with the "short-live" PIDs, and in fact, its implementation can be simplified, since only revocation data for PIDs with non-expired short-live PIDs must be considered. No need to keep revocation lists for PIDs issued 3 years ago, maybe just one week or one month.

[Sascha-Block]

Strengthening the Revocation Process through Short-term PIDs

Adopting short-term PIDs and minimizing the dependence on cumbersome revocation processes enhances the security, efficiency, and user experience of digital identity systems. This approach not only addresses the inherent weaknesses of long-term PIDs but also leverages modern cryptographic and operational practices to offer a robust framework suitable for contemporary digital interactions.

1. Reduction of Revocation Overhead: In traditional long-term PID systems, the revocation process is cumbersome and prone to errors. It requires the maintenance of extensive revocation lists that must be constantly updated and checked against by relying parties. This not only increases the administrative burden but also slows down the identity verification process. In contrast, the use of short-term PIDs simplifies this significantly. Since these PIDs expire quickly, the revocation list is inherently smaller and more manageable, containing only currently active or very recently expired PIDs. This makes the process more efficient and less prone to error or oversight.

2. Enhanced Security Posture: With long-term PIDs, the risk of an exposed or stolen PID remains a threat until the PID is explicitly revoked and this revocation is propagated to all relevant parties, which can take significant time. However, with short-term PIDs, even if a PID is compromised, its short lifespan limits the window of opportunity for misuse. Once expired, it is rendered useless without the need for explicit revocation, effectively minimizing the impact of any security breach.

3. Simplified Compliance and Lower Risk: The management of revocation lists is not only a technical challenge but also a compliance issue, with requirements to protect and accurately process personal data. Short-term PIDs, which need less frequent updates to revocation information, reduce the risk of non-compliance with data protection regulations like the GDPR. This streamlined approach not only enhances privacy protections but also reduces the risk of legal and regulatory penalties.

4. Immediate Effect of Revocation Decisions: In scenarios where a PID needs to be revoked due to compromise or other issues, the issuer can immediately stop issuing new short-term PIDs. This direct control mechanism is more effective compared to the delayed effect of updating and disseminating revocation lists in traditional systems. Once the short-term PID expires, the revoked status effectively takes hold without additional steps, closing any window for unauthorized use swiftly.

5. Reduced Operational Costs: Maintaining and distributing up-to-date revocation lists across multiple parties is costly. With short-term PIDs, these costs are drastically reduced. Fewer resources are required to manage the lifecycle of PIDs, leading to a decrease in operational costs for issuers and relying parties. User Experience and Trust: For users, the simplicity of not having to repeatedly authenticate or renew consent for each short-term PID issuance (once the initial long-term PID is in place) improves the user experience. It also builds trust, as users can be assured that their identifiers are managed securely and with minimal hassle, reducing the fatigue and resistance often associated with frequent security procedures.

[peppelinux]

Here the reason why in the implementations I'm working on, the refresh tokens are not used: https://github.com/italia/eudi-wallet-it-docs/issues/178

here the short-lived strategy for status assertions about the PID and or any other credentials https://www.ietf.org/id/draft-demarco-oauth-status-assertions-02.html

[Sascha-Block]

@peppelinux thx for the information, especially the reference to the OAuth Status Assertions Draft is valuable

[digeorgi]

Thank you very much for your contributions. Indeed, the possibility to use short-term attestations is beneficial both for security, privacy and simplicity - regarding the usage of large attestation revocation lists. PID issuance is the responsibility of the Member States. They can decide to implement either long-term PID or short-term PID, as some of them already have decided.

A related challenge is how the user must authenticate towards the PID Provider in case of short-lived PIDs. This aspect is not specified in the ARF and is to be decided upon by each PID Provider / Member State.