Summary of Digital Agency authentication app FIRST IMPRESSION

Last night (June 6st) at 21pm, we streamed on YouTube Live, titled "Digital Agency Authentication App FIRST IMPRESSION." The idea was to read the documentation together about the digital authentication app announced by the Digital Agency on the same day, and to identify its contents and issues. Although the announcement was made casually in the evening, and we started the stream without having enough time to prepare the talk deck, we managed to get up to 11 people, including senior officials of the Digital Agency, to watch the stream at the same time. We would like to express our deepest gratitude to everyone who participated. The archive can be viewed below. We recommend that you transition to YouTube, as there is a lot of information in the chat. The following is a summary of the AI1This is a summary by and notes I added as best I can remember. I may look back on it someday and add more.

However, looking back at it now, I realize I skipped over the part about signatures. That's a separate issue...

【Document】

要約

This live video discusses the Digital Agency's newly announced digital authentication app using My Number cards. The app allows for easy online identity verification on e-commerce sites, online banking, and reservations at public facilities. The video goes into detail on technical aspects such as how to register to use the app, the authentication process, and API references. It also touches on privacy policy, security, and how personal information is handled.

Key Point

00:00:08 Introduction

At the beginning of the video, it is explained that the Digital Agency will be discussing a new digital authentication app that uses the My Number card, which will make it easier to verify your identity on e-commerce sites and online banking.

00:01:00 App overview

The main usage scenarios for digital authentication apps include identity verification when logging in to e-commerce sites or online banking, online reservations for public facilities or sharing services, age verification, online identity verification, etc. It is an app that can be used in a wide range of fields, regardless of whether it is a private company or a government agency.

00:06:23 How to register

To use the app, you must first download the digital authentication app and check the terms of use and privacy policy. After that, you set up device authentication, enter your My Number card and PIN, and read your My Number card to complete your registration. Some people have raised doubts in the chat section about the necessity of registering.

  • The question of why this registration is necessary was raised during the broadcast. For example, if it was going to be used later in CIBA, it would make sense, but that is not the case.
    • In response to this, another commenter pointed out that it appears the PPID will be maintained so that the old and new serial numbers can be identified.5

00:10:09 Authentication process

The authentication process begins with the service launching a digital authentication app, where the user authenticates with their authentication certificate, then returns to the service in question. This process follows the standard OpenID Connect process. For cross-device authentication, a QR code must be read to link the devices.

  • The authentication process is as follows:OpenID Connect Core6 + OpenID Connect Session Management7+ PKCE [RFC7646]8The authentication app will be launched by the Digital Agency's OpenID Provider. There will be no direct interaction between the RP and the app.
  • For cross-device authentication, a QR code is read to link devices together.
  • Biometric authentication is required when launching the app, but there are doubts as to whether this is necessary.
  • There are two options for whether or not to provide attributes: accept all of them or reject all of them.

00:25:57 API Reference and Technical Aspects

It also explains technical aspects such as API reference, OpenID Connect settings, JWT usage, and the application of security best practices. It points out differences from the standard implementation, such as the location of some settings and handling of session management.

  • The specifications used are OpenID Connect Core + Discovery9 + Session Management + PKCE, OpenID Connect Backchannel Logout10, OAuth 2.0 Framework[RFC6749]11[RFC6750]12, JWT[RFC7519]13, J.W.K.RFC7517]14
  • The signature interface is a proprietary resource server. I would like this to be included as a standard.
    • (Postmortem thoughts: I wonder if this actually meets the ETSI remote signing specifications?)
  • Since the PPID is used as the user identifier, even if RPs collude with each other, they cannot match the user unless they obtain other attributes. This PPID appears to be maintained even if the certificate is changed.
  • Since PPID is one per person per RP, it can be used to issue coupons and tickets that are limited to one per person. Some articles on the street say that you should use the information on the ticket app, but that is unnecessary and it is better not to get one based on the principle of minimizing acquired information.
  • The location of openid-configuration in the document is incorrect. The correct location is:https://auth-and-sign.go.jp/api/realms/main/.well-known/openid-configuration And /api/ is missing.
  • Placing .well-known under /api/realms/main/ instead of directly under the domain is different from the standard.RFC578515It is supposed to be placed directly under the domain. So this is not well-known. It has been pointed out that KeyCloak is like this.16.
  • It has been pointed out that the proprietary scope "user_certificate_history" included in openid-configuration is of concern.
  • Authentication strength is aal3
  • Client authentication is via private key JWT.
  • API Reference (For private businessesAccording to the 2017 EAP-256 standard (for government agencies), both the access token and the refresh token are JWT. It has been pointed out that it would be better to stop using the refresh token even now.

00:40:56 Privacy and security

Group Privacy PolicyThe document explains how personal information will be handled, its retention period, and safety measures. The four basic pieces of information obtained by the authentication API will be deleted in one hour, but session information may be retained for a certain period of time. The document also discusses how to handle PPID, which can identify individuals.

About Privacy

  • The privacy policy is hard to read because it is typed in solid text. JIS X 925217 I would like them to be presented in a table format as recommended by the Ministry of Economy, Trade and Industry, etc. After all, this is the Japanese version of the international standard ISO/IEC 29184, which was created based on the METI guidelines.
  • As an independent privacy policy, it is unhelpful that it does not describe procedures for disclosure, correction, and deletion, and the full picture cannot be understood unless it is combined with the privacy policy of the Digital Agency as a whole. Both JIS X 9252 and the Smartphone Privacy Initiative recommend that this be written together in the app's privacy policy.
  • The FAQ states that the four basic pieces of information will be deleted in one hour, and the privacy policy only states "for a certain period of time." It is unclear how long information other than the four basic pieces of information will be retained.
  • The PPID issued here is personal data. Some "important people" seem to say that the PPID is not personal information, but that is incorrect.

About security

  • RFC911618The security.txt specified in the above also does not currently exist.
  • We need to look into it more carefully to see whether it is safe to link an authentication device and a consumption device with a QR code and a six-digit number. Formal analysis has shown that there are security issues with using QR codes when issuing OpenID for Verifiable Credentials, so it would be good to compare it properly.
  • This link requires you to register the app, so it seems like there could have been a way to use CIBA or something similar.
  • OpenID Connect Core + PKCE, not FAPI. OAuth Security Best Current Practice19 It would be a good idea to compare it with the above.
  • (Something I forgot to mention in the broadcast) I don't really understand how the Digital Agency's backend authenticates smartphone apps. I'd like more information on this as well.

Points to consider when streaming

Technical insight

This time I tried using YouTube's webcam streaming feature. I used mmhmm to share the screen. I usually use a MacBook Pro (M1Pro), but this time I tried using an M2 MacBook Air. As a result, I had some regrets and realizations.

  • The video was choppy, probably because the machine was underpowered. It seemed that thermal throttling had started halfway through, and the operation at hand was also choppy. It seems that it would be smoother to use the M1Pro MacBook Pro.
  • It's convenient to be able to do this without using OBS, but it's a bit disappointing that you can't display the chat screen on the screen.
  • Surprisingly, I didn't mind being able to display only two screens. (Maybe because the number of screens required is reduced due to OBS.)
  • Audio works normally with this configuration.
  • If you use a webcam, you end up with a close-up view of the screen when reading documents, which is unsightly. It seems better to use an avatar.

Content Notice

  • No matter how little time you have, prepare a talk deck. I forgot a lot of things I was supposed to talk about.
    • Client authentication for the app
    • The story of eKYC & IDA
    • In a sense, it's an Aggregated Claims model with the My Number Card as the Claims Source.
  • When I tried it, I received a lot of information from knowledgeable people in the comments section, and I personally gained much more from it than I had anticipated.
  • Although participants cannot post links in comments, I can, so I should have just posted a link in the comments saying something like, ``Let's take a look at this page.''

Potentially useful reference materials

Below, we will add materials that are not related to the distribution but may be useful from time to time.

Technical Analysis Articles

Reports, etc.

From X et al.

(Update history)

  • 2024-06-22 First edition
  • 2024-06-23
    • Correction for writing JIS X 9252 instead of JIS X 9250.
    • Adding useful resources
    • Insert references to cited standards
  • 2024-06-24
    • Includes comments made by kokumin_a on X regarding the procurement specifications

footnote

  1. https://www.notta.ai/
  2. Digital Agency (2024) Digital authentication app service site. https://services.digital.go.jp/auth-and-sign/ (Obtained on 2024-06-21)
  3. Digital Agency (2024) Digital Agency Developer Site. https://developers.digital.go.jp/ (Obtained on 2024-06-21)
  4. Koyama, Yasuhiro (2024)"Digital Agency's 'Authentication App' Aims to Be the 'Foundation for Online Identity Verification'"Impress watch
  5. It seems that the procurement specifications included a flow for linking the old and new serial numbers and registering them in the ID management database when registering users of the digital authentication app. https://x.com/kokumin_a/status/1804778856689160447
  6. 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 (Obtained on 2024-06-21)
  7. de Madeiros, et al. (2022) OpenID Connect Session Management 1.0. OpenID Foundation. https://openid.net/specs/openid-connect-session-1_0.html (Obtained on 2024-06-21)
  8. Sakimura, et al. (2015). RFC7636 Proof Key for Code Exchange by OAuth Public Clients. IETF. https://datatracker.ietf.org/doc/html/rfc7636 (Retrieved 2024-06-21).
  9. 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)
  10. 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 (Obtained on 2024-06-21)
  11. Hardt, et al. (2012) RFC6749 The OAuth 2.0 Authorization Framework. IETF. https://datatracker.ietf.org/doc/html/rfc6749 (Obtained on 2024-06-21)
  12. 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)
  13. Jones, et al. (2015). JSON Web Token (JWT). IETF. https://datatracker.ietf.org/doc/html/rfc7519
  14. Jones. (2015). JSON Web Key (JWK). IETF. https://datatracker.ietf.org/doc/html/rfc7517
  15. Nottingham. (2010). Defining Well-Known Uniform Resource Identifiers (URIs). IETF. https://datatracker.ietf.org/doc/html/rfc5785 (Obtained on 2024-06-21)
  16. Let's create a realm using the Keycloak Admin REST API. https://blog.linkode.co.jp/entry/2023/08/22/161335 (Obtained on 2024-06-21)
  17. JIS X 9252:2023 Information Technology - Online Privacy Notice and Consenthttps://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+X+9252%3A2023. Online viewing is free of charge.https://jisc.go.jp/app/jis/general/GnrJISSearch.html… You can view it by searching for "X9252" from here.
  18. Foudil. (2022). RFC9116 A File Format to Aid in Security Vulnerability Disclosure. IETF. https://datatracker.ietf.org/doc/html/rfc9116
  19. Lodderstedt. (2024). OAuth 2.0 Security Best Current Practice. IETF. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics (Obtained on 2024-06-21)

Leave a comment

This site uses Akismet to reduce spam.For details of how to process comment data, please click here.