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

[Michael Schwartz]

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

-- 





*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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250128/983fa525/attachment.htm>