Digital Agency Authentication App: First-Impression Summary

Last night (June 21), starting at 11 p.m., I held a YouTube Live stream titled “Digital Agency Authentication App: First Impressions.” The idea was to read through the documentation together and identify the features and issues of the Digital Authentication App announced by the Digital Agency that same day. Although I announced it rather casually that evening and started without even having time to prepare a talk deck, as many as 94 people—including senior Digital Agency officials—joined simultaneously. I sincerely thank everyone who participated. The recording is available below. I recommend opening it on YouTube because the chat contains a great deal of information. What follows is a summary produced by AI ¹, supplemented with as many notes as I can remember. I may watch it again and add more later.

Looking back, however, I see that I skipped the topic of signatures. I will cover that separately another time.

Watch this video on YouTube.
Playing the video connects to YouTube.

Resources

• Digital Authentication App Service Site ²
• Digital Agency Developer Site ³
• Yasuhiro Koyama (2024), “The Online Identity Verification Infrastructure Envisioned by the Digital Agency’s ‘Authentication App’,” Impress Watch.⁴

Summary

This live-stream video discusses the Digital Agency’s newly announced Digital Authentication App, which uses the My Number Card. The app enables simple online identity verification for e-commerce sites, online banking, public-facility reservations, and other services. The video explains technical aspects in detail, including registration for use, the authentication flow, and the API reference. It also addresses the privacy policy, security, and the handling of personal information.

Key Points

00:00:08 Introduction

At the beginning of the video, we explain that we will discuss the Digital Agency’s newly released Digital Authentication App, which uses the My Number Card. The app is intended to simplify identity verification for e-commerce sites and online banking.

00:01:00 App Overview

The main use cases described for the Digital Authentication App include identity verification when logging in to e-commerce sites and online banking, online reservations for public facilities and sharing services, age verification, and online identity verification. The app is intended for use across a wide range of fields by both private companies and government agencies.

00:06:23 How to Register

To use the app, you must first download the Digital Authentication App and review its terms of service and privacy policy. You then configure device authentication, enter the My Number Card PIN, scan the card, and complete registration. Questions about why this registration is necessary were also raised in the chat.

• During the stream, we questioned why this registration was necessary. It might make sense if it were later used for something like CIBA, but that is not how the system works.
  • Another comment noted that the system apparently preserves a PPID by keeping track of the old and new serial numbers.⁵

00:10:09 Authentication Flow

In the authentication flow, a service first launches the Digital Authentication App, and the user authenticates with an authentication certificate. The user then returns to the service. This follows the standard OpenID Connect flow. For cross-device authentication, a QR code must be scanned to link the devices.

• The authentication flow uses OpenID Connect Core⁶ + OpenID Connect Session Management⁷ + PKCE[RFC7646]⁸The app is launched by the Digital Agency’s OpenID Provider. The RP and the app do not communicate directly.
• For cross-device authentication, the user scans a QR code to link the devices.
• Biometric authentication is performed when the app launches, but questions were raised about whether this is necessary.
• For attribute release, the only options are to approve everything or reject everything.

00:25:57 API Reference and Technical Aspects

The video also explains technical aspects such as the API reference, OpenID Connect configuration, the use of JWTs, and the extent to which security best practices are applied. It points out that some configuration locations and the handling of session management differ from standard implementations.

• The specifications used are OpenID Connect Core + Discovery⁹ + Session Management + PKCE, OpenID Connect Backchannel Logout¹⁰, OAuth 2.0 Framework [RFC 6749]¹¹ [RFC 6750]¹², JWT [RFC 7519]¹³, JWK [RFC 7517]¹⁴
• The signing interface is a proprietary resource server. I would like to see this area conform to a standard.
  • (A thought afterward: might this actually conform to something such as the ETSI remote-signing specification?)
• A PPID is used as the user identifier, so even if RPs collude, they cannot correlate users unless they have obtained other attributes. This PPID apparently remains the same even when the certificate changes.
• Because each person has one PPID per RP, it can also be used to issue coupons or tickets limited to one per person. Some articles say this could be done using information from the card-face app, but that is unnecessary, and under the principle of data minimization it is better not to obtain that information.
• The location of openid-configuration stated in the documentation is incorrect. The correct location is https://auth-and-sign.go.jp/api/realms/main/.well-known/openid-configuration; the /api/ segment is missing.
• Placing .well-known under /api/realms/main/ rather than directly under the domain differs from the standard. (RFC 5785¹⁵ requires it to be placed directly under the domain.) Therefore, this is not well-known. One participant pointed out that Keycloak uses this structure¹⁶.
• A participant noted that the proprietary “user_certificate_history” scope in openid-configuration was concerning.
  • (A later observation) It appears to be intended for retrieving the history of the electronic certificate for user authentication from UserInfo, which is available only to government agencies. (Source: https://x.com/_nat/status/1804179314960929018)
• The authentication assurance level is AAL 3.
• Client authentication uses private key JWT.
• The API references (for private-sector businesses and for government agencies) show both access tokens and refresh tokens as JWTs. One participant noted that, especially for refresh tokens, it would be better to change this even now.

00:40:56 Privacy and Security

The privacy policy explains the handling and retention periods of personal information and the security safeguards. The basic 4 data items obtained through the authentication API are deleted after 1 hours, while session information and other data may be retained for some period. The treatment of personally identifiable PPIDs is also discussed.

Privacy

• The privacy policy is plain text and difficult to read. I would like it to use a table or another format, as recommended by JIS X 9252¹⁷ This is, after all, the Japanese version of ISO/IEC 29184, an international standard based on guidelines from Japan’s Ministry of Economy, Trade and Industry.
• Viewed as a standalone privacy policy, it is unfriendly because it does not describe procedures for disclosure, correction, or deletion, and the complete picture is available only by reading it together with the Digital Agency’s general privacy policy. Both JIS X 9252 and the Smartphone Privacy Initiative recommend consolidating this information in the app’s privacy policy.
• The FAQ says that the basic 4 data items are deleted after 1 hours, while the privacy policy says only “after a certain period.” It is unclear how long information other than the basic 4 data items is retained.
• The PPID issued here is personal data. Some “senior figures” apparently claim that a PPID is not personal information, but they are mistaken.

Security

• There is currently no security.txt file as specified in RFC 9116¹⁸.
• Whether linking an Authentication Device and a Consumption Device using a QR code and a 6-digit number is secure requires more careful analysis. Formal analysis has shown that the use of QR codes in the issuance flow for OpenID for Verifiable Credential has security problems, so it would be useful to compare this design with those findings.
• Since the app requires registration anyway, it seems that this linking step could have been implemented in another way, such as by using CIBA.
• The system uses OpenID Connect Core + PKCE and is not FAPI. It would be useful to compare it with OAuth Security Best Current Practice¹⁹.
• (A point I forgot to mention during the stream) It is unclear how the Digital Agency’s backend authenticates the smartphone app. I would like to see information about this disclosed as well.

Reflections on Running the Stream

Technical Observations

This time I used YouTube’s webcam streaming feature. I used mmhmm for the camera so that I could share my screen as well. I normally use a MacBook Pro (M 1 Pro), but this time I tried an M 2 MacBook Air. This produced several lessons and observations.

• Perhaps the machine lacks power, because the video stutters. It also appeared to start thermal throttling partway through, and even my local controls became sluggish. An M 1 Pro MacBook Pro would probably be smoother.
• It is convenient to stream without OBS, but it is a little disappointing that the chat cannot be shown on screen.
• I was surprised that being limited to 2 screens did not bother me. Perhaps that is because I did not need a screen for OBS.
• Audio works normally with this setup.
• When using a webcam, leaning in to read documents shown on the screen creates an unattractive extreme close-up. Using an avatar would probably work better.

Observations About the Content

• No matter how little time there is, prepare at least a talk deck. I forgot many of the things I had intended to discuss.
  • Client authentication for the app
  • eKYC & IDA
  • In one sense, this is an Aggregated Claims model with the My Number Card as the Claims Source, and so on.
• Once I actually ran the stream, experts in the comments contributed a great deal of information, and I personally gained far more from it than I had expected.
• Participants cannot post links in the comments, but I can. I should have posted links with prompts such as, “Let’s look at this page.”

Potentially Useful Resources

The following resources are unrelated to the stream, but I will add potentially useful material here from time to time.

Technical Analysis Articles

• ritou (2024), “Standard Specifications and Key Points Used for Identity Federation with the Digital Authentication App”
• Naohiro Fujie (2024), “The Digital Authentication App Is Coming (Follow-up)”, IdM Laboratory.

News Coverage and Other Reports

• Masako Wakae (2024-04-24), “The Digital Agency’s ‘Digital Authentication App’ Goes Astray: Risk of Online Usage History Being Centralized in Government”, Yomiuri Shimbun.
• Kentaro Uechi (2024-06-21), “Online Identity Verification Makes the My Number Card Easier to Use—but Will Usage Data Go to the Government? Concerns Remain”, Asahi Shimbun.
• Yasuhiro Koyama (2024-06-21), “The Online Identity Verification Infrastructure Envisioned by the Digital Agency’s ‘Authentication App’”, Impress Watch.

From X and Other Sources

デジタル認証アプリの利用者登録の中で、新旧シリアル番号を紐付けてID管理DBに登録するフローが調達仕様書に書いてありました。

出典：令和５年度　個人向け認証アプリケーションの開発 調達仕様書（デジタル庁）（公開終了済み） https://t.co/APojbNHeKj pic.twitter.com/VOObFUsQdK

返信先: @rocazさん
観ながら書いてたんだけど、「証明書更新してもRPのPPIDを変更させない(ためにユニークな内部ユーザーIDの特定が必要」との意見がyoutube.com/live/OniXFjcmf… に。なるほど、そうですね

Revision History

• 2024-06-22 First edition
• 2024-06-23
  • Corrected a reference that should have said JIS X 9252 but instead said JIS X 9250
  • Added potentially useful resources
  • Inserted references for the cited standards
• 2024-06-24
  • Added kokumin_a’s observation on X concerning the procurement specification

1. https://www.notta.ai/
2. Digital Agency (2024), Digital Authentication App Service Site. https://services.digital.go.jp/auth-and-sign/ (retrieved 2024-06-21)
3. Digital Agency (2024), Digital Agency Developer Site. https://developers.digital.go.jp/ (retrieved 2024-06-21)
4. Yasuhiro Koyama (2024), “The Online Identity Verification Infrastructure Envisioned by the Digital Agency’s ‘Authentication App’,” Impress Watch.
6. It seems the procurement specification described a flow in which the old and new serial numbers are linked during registration for the Digital Authentication App and recorded in an identity-management database. From https://x.com/kokumin_a/status/1804778856689160447
7. Sakimura, et al. (2023) OpenID Connect Core 1.0 incorporating errata set 2. OpenID Foundation. https://openid.net/specs/openid-connect-core-1_0.html (retrieved 2024-06-21)
8. de Madeiros, et al. (2022) OpenID Connect Session Management 1.0. OpenID Foundation. https://openid.net/specs/openid-connect-session-1_0.html (retrieved 2024-06-21)
9. Sakimura, et al. (2015). RFC 7636 Proof Key for Code Exchange by OAuth Public Clients. IETF. https://datatracker.ietf.org/doc/html/rfc7636 (retrieved 2024-06-21).
10. Sakimura, et al. (2023). OpenID Connect Discovery 1.0 incorporating errata set 2. OpenID Foundation. https://openid.net/specs/openid-connect-discovery-1_0.html. (retrieved 2024-06-21)
11. Jones, et al. (2023). OpenID Connect Back-Channel Logout 1.0 incorporating errata set 1. OpenID Foundation. https://openid.net/specs/openid-connect-backchannel-1_0.html (retrieved 2024-06-21)
12. Hardt, et al. (2012) RFC 6749 The OAuth 2.0 Authorization Framework. IETF. https://datatracker.ietf.org/doc/html/rfc6749 (retrieved 2024-06-21)
13. Jones, et al. (2012) The OAuth 2.0 Authorization Framework: Bearer Token Usage. IETF. https://datatracker.ietf.org/doc/html/rfc6750. (retrieved 2024-06-21)
14. Jones, et al. (2015). JSON Web Token (JWT). IETF. https://datatracker.ietf.org/doc/html/rfc7519
15. Jones. (2015). JSON Web Key (JWK). IETF. https://datatracker.ietf.org/doc/html/rfc7517
16. Nottingham. (2010). Defining Well-Known Uniform Resource Identifiers (URIs). IETF. https://datatracker.ietf.org/doc/html/rfc5785 (retrieved 2024-06-21)
17. Creating a Realm with Keycloak’s Admin REST API. https://blog.linkode.co.jp/entry/2023/08/22/161335 (retrieved 2024-06-21)
18. JIS X 9252:2023 Information technology—Online privacy notices and consent. https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+X+9252%3A2023. It can be viewed online free of charge at https://jisc.go.jp/app/jis/general/GnrJISSearch.html…; search there for “X 9252.”
19. Foudil. (2022). RFC 9116 A File Format to Aid in Security Vulnerability Disclosure. IETF. https://datatracker.ietf.org/doc/html/rfc9116
20. Lodderstedt. (2024). OAuth 2.0 Security Best Current Practice. IETF. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics (retrieved 2024-06-21)