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

[sm-tanaka at kddi.com]

Dear Joseph and Mike,

Thank you for your response.
Attestation-Based Client Authentication that you recommended can be one of the solutions.

According to the specifications, the steps where the Client Instance receives the Client Attestation JWT from the Client Backend are out of scope, 
therefore we are assuming that the Authorization Server can also issue the Client Attestation JWT.

Since all of our applications are developed in-house, we can verify the legitimacy of the application based on the results of DeviceCheck and SafetyNet on the Authorization Server.
Therefore, we want to create client attestation on the Authorization Server.

Do you think it is acceptable? Also, is there any spec regarding protocols to issue the Client Attestation JWT?

Best Regards,

-----Original Message-----
From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Michael Schwartz via Openid-specs-ab
Sent: Tuesday, January 28, 2025 9:15 PM
To: openid-specs-ab at lists.openid.net
Cc: Michael Schwartz <mike at gluu.org>
Subject: Re: [Openid-specs-ab] [Openid-specs-mobile-profile] How to authenticate mobile apps with private-key-jwt without issuing ClientIDs or managing public keys

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: https://gluu.co/ioh-wiki-81

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. 

Mike

On Tue, Jan 28, 2025, 9:56 AM sm-tanaka at kddi.com <mailto:sm-tanaka at kddi.com>  <sm-tanaka at kddi.com <mailto:sm-tanaka at kddi.com> > 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 <mailto:sm-tanaka at kddi.com> 
	--------------------------------------------------
	この電子メールおよび添付書類は、名宛人のための特別
	な秘密情報を含んでおります。そのため、名宛人以外の
	方による利用は認められておりません。
	名宛人以外の方による通信内容公表、複写、転用等は厳
	禁であり、違法となることがあります。
	万が一、何らかの誤りによりこの電子メールを名宛人以
	外の方が受信された場合は、お手数でも直ちに発信人に
	お知らせ頂くと同時に、当メールを削除下さいますよう
	お願い申し上げます。
	
	_______________________________________________
	Openid-specs-mobile-profile mailing list
	Openid-specs-mobile-profile at lists.openid.net <mailto:Openid-specs-mobile-profile at lists.openid.net> 
	https://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
	


 <https://github.com/GluuFederation/docs-gluu-server-prod/blob/master/docs/source/small_logo.png?raw=true> 

________________________________

CONFIDENTIALITY NOTICE

This message may contain confidential or legally privileged information.
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.
Thank you for your cooperation