[Openid-specs-ab] How to authenticate mobile apps with private-key-jwt without issuing ClientIDs or managing public keys

[Joseph Heenan]

Dear Tanaka san

The way the similar problem is being solved in wallet ecosystems is with this proposed specification:

https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/

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.

Joseph


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250128/064b183d/attachment-0001.htm>