<div dir="ltr"><div dir="ltr"><div>Tanaka-san,</div><div><br></div><div>Sorry for the delayed response! You asked: </div><div><br></div><div>>>> According to the specifications, the steps where the Client Instance receives the <br>>>> Client Attestation JWT from the Client Backend are out of scope, therefore we are <br>>>> assuming that the Authorization Server can also issue the Client Attestation JWT. </div><div><br></div><div>If the AS issues the Client Attestation JWT, it's basically a "software statement" or SSA "software statement assertion." : <br><a href="https://datatracker.ietf.org/doc/html/rfc7591#section-2.3" target="_blank">https://datatracker.ietf.org/doc/html/rfc7591#section-2.3</a><br><br>IMHO, it makes a lot of sense for the AS to also issue SSAs. In some cases, the federation will issue the SSA (e.g. Open Banking federations). <br><br>In Jans Auth Server there is an SSA issuance endpoint: <a href="https://gluu.org/swagger-ui/?url=https://raw.githubusercontent.com/JanssenProject/jans/v1.4.0/jans-auth-server/docs/swagger.yaml#/SSA" target="_blank">https://gluu.org/swagger-ui/?url=https://raw.githubusercontent.com/JanssenProject/jans/v1.4.0/jans-auth-server/docs/swagger.yaml#/SSA</a> The key rotation period for SSA keys is longer than for normal OpenID Connect keys--giving developers an SSA that expires in two days would be annoying. Otherwise, SSA endpoint is trivial of course. </div><div><br>Just as an example, below is a screenshot from the Janssen TUI (text ui): a form that enables an Auth Server admin to create an SSA.</div><div><br></div><div><img src="cid:ii_m73tus4f0" alt="add_ssa-tui-panel.png" width="490" height="178"><br></div><div><br></div><div>Beyond a domain-specific SSA, I would also want an attestation from the platform before I allowed dynamic client registration. Google and Apple both have integrity APIs. If the checksum of the app has changed from the App Store or the phone is rooted, you don't want to allow that client to register.</div><div><br></div><div>My understanding is that ABC authentication is used for one-time privacy protecting use cases. It's a wallet use case--your wallet is a client, but it's only going to interact once--no need for a client entity at the OP. And an rp_id would be bad for privacy. So the RP just makes an attestation about its security properties--I have this kind of private key protection...</div><div><br></div><div>If high assurance is needed, enterprises will want a unique client entity for a mobile app--asymmetric client secrets are better. Operationally, domains may want to have a short lifetime on dynamically registered client entities. For example, OOTB dynamic client registration expiration is one day in Jans Auth Server. </div><div><br></div><div>Post-DCR, you can allow the client to proceed with FIDO enrollment for the human. Or perhaps the person can present a Verifiable Credentia from a wallet. <br><br></div><div>One other challenge for mobile developers is how to validate JWTs and map them to access policies. One of the Gluu devs wrote this article recently: <a href="https://medium.com/@arnab.bdutta/janssen-cedarling-uniffi-bindings-for-native-apps-90f36982c894" target="_blank">https://medium.com/@arnab.bdutta/janssen-cedarling-uniffi-bindings-for-native-apps-90f36982c894</a>. </div><div><br></div><div>IMHO, you want the "jti" of all the tokens in the PDP decision log for all actions, to have a complete cryptographic chain of custody for the person, workload, and policy store version. </div><div><br></div><div>One more resource we wrote a while back that you might find of interest: <br><a href="https://github.com/JanssenProject/jans/wiki/Mobile-DPoP-FIDO-Authn" target="_blank">https://github.com/JanssenProject/jans/wiki/Mobile-DPoP-FIDO-Authn</a> <br>This has been implemented as part of the Jans Chip demo:</div><div><a href="https://github.com/JanssenProject/jans/tree/main/demos/jans-chip/android" target="_blank">https://github.com/JanssenProject/jans/tree/main/demos/jans-chip/android</a></div><div><br></div><div>Hope that helps! </div><div dir="ltr"><br></div><div>- Mike </div><div><br></div><div>--------------------------------------<br>Michael Schwartz<br>Gluu<br>Founder/CEO<br><a href="mailto:mike@gluu.org">mike@gluu.org</a><br><a href="https://www.linkedin.com/in/nynymike">https://www.linkedin.com/in/nynymike</a></div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><br>
Message: 2<br>
Date: Thu, 30 Jan 2025 09:36:39 +0000<br>
From: "<a href="mailto:sm-tanaka@kddi.com" target="_blank">sm-tanaka@kddi.com</a>" <<a href="mailto:sm-tanaka@kddi.com" target="_blank">sm-tanaka@kddi.com</a>><br>
To: Artifact Binding/Connect Working Group<br>
<<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>>,<br>
"<a href="mailto:openid-specs-mobile-profile@lists.openid.net" target="_blank">openid-specs-mobile-profile@lists.openid.net</a>"<br>
<<a href="mailto:openid-specs-mobile-profile@lists.openid.net" target="_blank">openid-specs-mobile-profile@lists.openid.net</a>><br>
Cc: "<a href="mailto:id-contact@kddi.com" target="_blank">id-contact@kddi.com</a>" <<a href="mailto:id-contact@kddi.com" target="_blank">id-contact@kddi.com</a>><br>
Subject: Re: [Openid-specs-ab] [Openid-specs-mobile-profile] How to<br>
authenticate mobile apps with private-key-jwt without issuing<br>
ClientIDs or managing public keys<br>
Message-ID:<br>
<<a href="mailto:TYWPR01MB12102660486FC9CC580C123F794E92@TYWPR01MB12102.jpnprd01.prod.outlook.com" target="_blank">TYWPR01MB12102660486FC9CC580C123F794E92@TYWPR01MB12102.jpnprd01.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Dear Joseph and Mike,<br>
<br>
Thank you for your response.<br>
Attestation-Based Client Authentication that you recommended can be one of the solutions.<br>
<br>
According to the specifications, the steps where the Client Instance receives the Client Attestation JWT from the Client Backend are out of scope, <br>
therefore we are assuming that the Authorization Server can also issue the Client Attestation JWT.<br>
<br>
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.<br>
Therefore, we want to create client attestation on the Authorization Server.<br>
<br>
Do you think it is acceptable? Also, is there any spec regarding protocols to issue the Client Attestation JWT?<br>
<br>
Best Regards,<br>
<br>
-----Original Message-----<br>
From: Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>> On Behalf Of Michael Schwartz via Openid-specs-ab<br>
Sent: Tuesday, January 28, 2025 9:15 PM<br>
To: <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
Cc: Michael Schwartz <<a href="mailto:mike@gluu.org" target="_blank">mike@gluu.org</a>><br>
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<br>
<br>
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" rel="noreferrer" target="_blank">https://gluu.co/ioh-wiki-81</a><br>
<br>
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. <br>
<br>
Mike<br>
<br>
On Tue, Jan 28, 2025, 9:56?AM <a href="mailto:sm-tanaka@kddi.com" target="_blank">sm-tanaka@kddi.com</a> <mailto:<a href="mailto:sm-tanaka@kddi.com" target="_blank">sm-tanaka@kddi.com</a>> <<a href="mailto:sm-tanaka@kddi.com" target="_blank">sm-tanaka@kddi.com</a> <mailto:<a href="mailto:sm-tanaka@kddi.com" target="_blank">sm-tanaka@kddi.com</a>> > wrote:<br>
<br>
<br>
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" target="_blank">https://www.kddi.com/corporate/kddi/purpose/</a><br><br>
</blockquote></div></div>
</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>