<div dir="auto">Did you look at the IETF draft "ABC Authentication" -- Attestation Based Client Authn? This is good for situations where you have a one time authn, as is the case with many wallet use cases. Check out the IOH livestream on this topic: <a href="https://gluu.co/ioh-wiki-81">https://gluu.co/ioh-wiki-81</a><div dir="auto"><br></div><div dir="auto">IMHO, if it's your mobile app, and you expect continued authentications, is it really a "vast" amount of client entities? AI captures vast amounts of data, but you don't have enough room to store a relatively small amount of days about this critical metadata about a trusted device, that you plan to interact with for years to come? If security is important enough to you that you want to do private key authn, maybe it's worth keeping device entity metadata. Also, you can consider expiring client registrations that are unused to clean the data periodically. </div><div dir="auto"><br></div><div dir="auto">Mike</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Jan 28, 2025, 9:56 AM <a href="mailto:sm-tanaka@kddi.com">sm-tanaka@kddi.com</a> <<a href="mailto:sm-tanaka@kddi.com">sm-tanaka@kddi.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
<a href="https://www.kddi.com/corporate/kddi/purpose/" rel="noreferrer noreferrer" target="_blank">https://www.kddi.com/corporate/kddi/purpose/</a><br>
<br>
KDDI Sustainable Action<br>
～私たちの『つなぐチカラ』は、未来のためにある～<br>
<a href="https://www.kddi.com/corporate/csr/sdgs/" rel="noreferrer noreferrer" target="_blank">https://www.kddi.com/corporate/csr/sdgs/</a><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：<a href="mailto:sm-tanaka@kddi.com" target="_blank" rel="noreferrer">sm-tanaka@kddi.com</a><br>
--------------------------------------------------<br>
この電子メールおよび添付書類は、名宛人のための特別<br>
な秘密情報を含んでおります。そのため、名宛人以外の<br>
方による利用は認められておりません。<br>
名宛人以外の方による通信内容公表、複写、転用等は厳<br>
禁であり、違法となることがあります。<br>
万が一、何らかの誤りによりこの電子メールを名宛人以<br>
外の方が受信された場合は、お手数でも直ちに発信人に<br>
お知らせ頂くと同時に、当メールを削除下さいますよう<br>
お願い申し上げます。<br>
<br>
_______________________________________________<br>
Openid-specs-mobile-profile mailing list<br>
<a href="mailto:Openid-specs-mobile-profile@lists.openid.net" target="_blank" rel="noreferrer">Openid-specs-mobile-profile@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile" rel="noreferrer noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</a><br>
</blockquote></div>
<br>
<div></div><div></div><div><font size="1"><img src="https://github.com/GluuFederation/docs-gluu-server-prod/blob/master/docs/source/small_logo.png?raw=true"><br></font></div><div><hr></div><div><font size="1"><b style="color:rgb(128,128,128);font-family:"Sans Serif"">CONFIDENTIALITY NOTICE</b><br></font></div><font face="Sans Serif" color="#808080" size="1">This message may contain confidential or legally privileged information.<br>If you are not the intended recipient, please immediately advise the sender by reply e-mail that you received this message, and delete this e-mail from your system.<br>Thank you for your cooperation</font><br>