Introduction

Hello, I'm Ryo, a developer of ID Platform in the Global Development Group. I participated in the OpenID Summit at Shibuya Stream Hall on January 19th 2024, so I am writing this article to share my impressions and the interesting points I found. Due to the COVID-19 pandemic, the summit was held for the first time in four years since the OpenID Summit Tokyo 2020. It was very exciting as many people who are interested in OpenID gathered at the venue on the day of the event. The topic this time was regarding what kind of change digital identity has brought about in the four years surrounding the COVID-19 pandemic, and what kind of development digital identity is likely to take place in the world in the future.

Program Flow

Impressions

OpenID is not a very well known topic compared to other highly versatile technology fields, and I think there are many people who have never heard of it. However, when I arrived at the summit venue, there were many people who were interested in OpenID from many companies. I was a little surprised. Some people were attending for the first time, so in the morning, we were introduced to the history of OpenID's development so far, the future development and outlook for OpenID in the areas of digital identity and electronic money, and details of the translation of materials and human resource development activities being carried out by the OpenID Foundation Japan Working Group. From the content presented in the morning, I deeply felt that the future direction of OpenID development is changing from the area of authentication and authorization to identity verification (digital identity) and electronic payments management.
As for the topics presented in the afternoon, each company explained the problems encountered during the implementation and operation stage of OpenID and the overall solutions and countermeasures. However, the afternoon program was held at two different venues, and since I cannot make copies of myself like Naruto, unfortunately I could not attend both at the same time.

Impressive presentation

Consideration of countermeasures against spoofing attacks when using OpenID Connect

Presenter: Junki Yuasa (Nara Institute of Science and Technology, Laboratory for Cyber Resilience). The case presented here is quite rare, but I was surprised that a second-year master's student had delved so deeply into OpenID operation experiments. Although there are several authentication modes for OpenID, security may be low depending on the usage scenario, so I think that in future developments, we should be careful about risky parts in specific cases like this one.

Mercari App Access Token

Presenter: Nguyen Da (Mercari, Inc. ID Platform Team Software Engineer ). The Mercari App is well-known in Japan as a very popular online second hand marketplace. The ID Platform Engineer explained how Mercari ID faced some difficulties with the old method of operation, and how they worked to make it easier for users to use the service on the mobile app and browser. With that, I learned that although we have achieved many goals in utilizing browser cookies, only Chrome browsers have special specifications, with a cookie validity period of 400 days. Since we launched our ID platform, we have gone through many challenges and efforts regarding UI and UX, but I learned for the first time that the cookie validity period is 400 days.

About JWT

You may have heard of the name JWT (JSON Web Token), but if you are not familiar with authentication and authorization, you may not have had a chance to learn about the role of JWT or the interrelationship between JWK, JWS, and JWE, which are often mentioned together. So let me give a brief explanation in advance:

1. JWT is a standard for ensuring the reliability of information exchanged on a network. Among them, JWS and JWE are examples of the implementation of the JWT standard.
2. JWS (JSON Web Signature) uses "." as shown in the figure below.It is divided into three parts: ** Header (authentication method), Payload (actual information), Signature (guarantee against tampering)**. JWS has been base64 encoded, so the decoded Payload has all the information disclosed.
3. According to the explanation of JWT, JWK (Json Web Key) is an encryption key that is written in the JWT Header and used to encrypt the hash of the Payload contents to generate a Signature.
4. JWE (JSON Web Encryption) is a JWT that can protect the safety and integrity of the JWS mentioned above. So, it was divided into five parts using ".", with the second being a Payload-specific code that serves as the decryption key. Only the owner of the encryption key can decrypt the contents of the Payload. Source

SD-JWT

At this OpenID Summit, Italy's track record of electronic money implementation and operation was introduced. Here, they explained a new concept for me called SD-JWT. This was the first time I had heard of it, so I looked it up myself after the summit ended. From here on, we will finally delve into the main subject of this article. I would like to briefly explain what I found about SD-JWT. Selective Disclosure JWT (SD-JWT) is, as the name suggests, a JWT in which particular information is only disclosed to selected parties. I will first explain the background to the design of SD-JWT, when JWS and JWE already exist in the world. There are currently two types of Payload disclosures:

• Full Disclosure: Anyone can parse the JWS using base64 and see everything in the payload.
• Complete confidentiality: In the case of JWE, the contents of the JWE payload cannot be seen by anyone other than the owner who has the decryption key.
  However, there is no solution for cases where you only want to disclose some information. That is why SD-JWT was born. For example, when an electronic wallet owner purchases a product worth 100,000 yen, they do not need to see the general attribute information (birthday, address, phone number, etc.) that the product seller uses to authenticate the buyer, and they only want to see the buyer's electronic wallet balance. As a buyer, you can make a purchase by disclosing only essential information such as your balance and ID without disclosing all your personal information. This alone may not be enough, but it is effective to prevent leakage of personal information to a certain extent by disclosing only the necessary information of the owner from the JWS to the business operator.

How to implement SD-JWT

Let's start with the traditional ID token generation procedure. First, display the personal information of a certain user A in JSON format as shown below.

{
  "sub": "cd48414c-381a-4b50-a935-858c1012daf0",
  "given_name": "jun",
  "family_name": "liang",
  "email": "jun.liang@example.com",
  "phone_number": "+81-080-123-4567",
  "address": {
    "street_address": "123-456",
    "locality": "shibuya",
    "region": "Tokyo",
    "country": "JP"
  },
  "birthdate": "1989-01-01"
}

The issuer then assigns an SD-JWT Salt (random value) to each attribute information.

{
  "sd_release": {
    "sub": "[\"2GLC42sKQveCfGfryNRN9c\", \"cd48414c-381a-4b50-a935-858c1012daf0\"]",
    "given_name": "[\"eluV5Og3gSNII8EYnsxC_B\", \"jun\"]",
    "family_name": "[\"6Ij7tM-a5iVPGboS5tmvEA\", \"liang\"]",
    "email": "[\"eI8ZWm9QnKPpNPeNen3dhQ\", \"jun.liang@example.com\"]",
    "phone_number": "[\"Qg_O64zqAxe412a108iroA\", \"+81-080-123-4567\"]",
    "address": "[\"AJx-095VPrpTtM4QMOqROA\", {\"street_address\": \"123-456\", \"locality\": \"shibuya\", \"region\": \"Tokyo\", \"country\": \"JP\"}]",
    "birthdate": "[\"Pc33CK2LchcU_lHggv_ufQ\", \"1989-01-01\"]"
  }
}

The attribute information of "sd_release" is calculated using the hash function specified in "_sd_alg" and stored in "_sd" below, and a new payload can be created by adding the issuer's signing key (cnf), validity period (ext), and issuance time (iat). The latest token is issued based on the payload, and the SD-JWT has been created.

{
  "kid": "tLD9eT6t2cvfFbpgL0o5j/OooTotmvRIw9kGXREjC7U=",
  "alg": "RS256"
}.
{
  "_sd": [
    "5nXy0Z3QiEba1V1lJzeKhAOGQXFlKLIWCLlhf_O-cmo",
    "9gZhHAhV7LZnOFZq_q7Fh8rzdqrrNM-hRWsVOlW3nuw",
    "S-JPBSkvqliFv1__thuXt3IzX5B_ZXm4W2qs4BoNFrA",
    "bviw7pWAkbzI078ZNVa_eMZvk0tdPa5w2o9R3Zycjo4",
    "o-LBCDrFF6tC9ew1vAlUmw6Y30CHZF5jOUFhpx5mogI",
    "pzkHIM9sv7oZH6YKDsRqNgFGLpEKIj3c5G6UKaTsAjQ",
    "rnAzCT6DTy4TsX9QCDv2wwAE4Ze20uRigtVNQkA52X0"
  ],
  "iss": "https://example.com/issuer",
  "iat": 1706075413,
  "exp": 1735689661,
  "_sd_alg": "sha-256",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "SVqB4JcUD6lsfvqMr-OKUNUphdNn64Eay60978ZlL74",
      "y": "lf0u0pMj4lGAzZix5u4Cm5CMQIgMNpkwy163wtKYVKI",
      "d": "0g5vAEKzugrXaRbgKG0Tj2qJ5lMP4Bezds1_sTybkfk"
    }
  }
}.
{
  Signature
  The issuer calculates the Payload signature with the public key and places it here, ensuring that the contents of the Payload are not tampered with
}

The order of the attributes and hash values ​​of "sd_release" and "_sd" does not need to be maintained.

How to use SD-JWT

The issuer sends the SD-JWT and "sd_release" together to the owner. Depending on the usage situation, the owner can submit the attribute information they want to disclose and the SD-JWT at the same time, allowing authentication while maintaining safety and integrity.

  "email": "[\"eI8ZWm9QnKPpNPeNen3dhQ\", \"jun.liang@example.com\"]",

If you only want to disclose your e-mail address, you will need to submit the above part together with the SD-JWT. The verifier can check the accuracy of the email by checking the following two points

• The result of calculating the e-mail portion with the hash function matches "5nXy0Z3QiEba1V1lJzeKhAOGQXFlKLIWCLlhf_O-CMO" in the "_sd " list
• The signature recalculation result of the Payload matches the signature in SD-JWT (the Payload has not been tampered with).

Summary

By participating in this summit, I was able to understand the history and future development of OpenID. In addition, I learned about SD-JWT, which is a different format from the JWT that the ID team has used so far. There were many interesting discussions, so I recommend participating even if you are not usually involved in the field of ID. I am looking forward to being able to join as a speaker one day representing KINTO Technologies in the future.

Reference

OpenID Summit Tokyo 2024