<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Dear Tanaka san<div><br></div><div>The way the similar problem is being solved in wallet ecosystems is with this proposed specification:</div><div><br></div><div><a href="https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/">https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/</a><br id="lineBreakAtBeginningOfMessage"><div><br></div><div>The quick summary is that the mobile app would use something like Apple’s DeviceCheck or Google’s safety net to get a signed assertion from the mobile app’s backend that a particular public key belongs to that app, then it would pass that signed assertion along with a proof of possession for that key to the authorization server.</div><div><br></div><div>Joseph</div><div><br></div><div><br><blockquote type="cite"><div>On 28 Jan 2025, at 08:37, sm-tanaka--- via Openid-specs-ab <openid-specs-ab@lists.openid.net> wrote:</div><br class="Apple-interchange-newline"><div><div>Dear Members of AB/Connect Working Group and MODRNA Working Group,<br><br><br>I hope this message finds you well.<br><br>We are considering implementing client authentication using private-key-jwt on mobile apps.<br>In this context, we have identified the following challenges:<br><br>Since the key pairs generated within devices differ for each device,<br>we need an identifier on the server side to determine which device's public key is being used.<br>One potential solution is to issue a Client ID for each device during "OpenID Connect Dynamic Client Registration 1.0" process.<br>However, this raises the issue of managing a vast number of client IDs on the server side.<br>To address this issue, I would appreciate your insights on the following two questions:<br><br>Though the vast number of Client IDs appears to be a challenge unique to mobile use cases,<br>I believe similar challenges may exist in the context of wallet use cases.<br>Are there any proposed solutions or discussions about this issue in the standard specifications?<br><br>We are considering having the server issue the public key certificate for the application's public key.<br>Thereafter, the application would present both the client assertion and the public key certificate,<br>allowing the server to validate the client assertion without storing the public key.<br>We would like to implement this in accordance with standard specifications.<br>Is there a standard method to embed the public key certificate within the JWT of the client assertion?<br>I found that RFC 7515, section 4.1.6 proposes a method for embedding public key certificate in the JWT header.<br>Is RFC 7515 applicable to our use case?, and are there any real use cases that utilize RFC 7515?<br><br>Thank you for your time and assistance. I look forward to your insights on these matters.<br><br>Best regards,<br>--<br>--------------------------------------------------<br>Tomorrow, Together KDDI<br> https://www.kddi.com/corporate/kddi/purpose/<br><br>KDDI Sustainable Action<br> ～私たちの『つなぐチカラ』は、未来のためにある～<br> https://www.kddi.com/corporate/csr/sdgs/<br>--------------------------------------------------<br>田中 翔真 (Shoma Tanaka)<br>ＫＤＤＩ株式会社<br>パーソナル事業本部<br>パーソナルシステム本部<br>アプリケーション開発部<br>アプリケーション1グループ<br><br>〒102-8460<br>東京都千代田区飯田橋3-10-10<br>ガーデンエアータワー<br>TEL：070-3508-2278（直通）<br>E-mail：sm-tanaka@kddi.com<br>--------------------------------------------------<br>この電子メールおよび添付書類は、名宛人のための特別<br>な秘密情報を含んでおります。そのため、名宛人以外の<br>方による利用は認められておりません。<br>名宛人以外の方による通信内容公表、複写、転用等は厳<br>禁であり、違法となることがあります。<br>万が一、何らかの誤りによりこの電子メールを名宛人以<br>外の方が受信された場合は、お手数でも直ちに発信人に<br>お知らせ頂くと同時に、当メールを削除下さいますよう<br>お願い申し上げます。<br><br>_______________________________________________<br>Openid-specs-ab mailing list<br>Openid-specs-ab@lists.openid.net<br>https://lists.openid.net/mailman/listinfo/openid-specs-ab<br></div></div></blockquote></div><br></div></body></html>