Hi Christian,
That would be great!
Related to this thread, I think it would be a good idea to add an
Implementation Consideration discussing the intent of the authors as Paul
noted. I imagine it will be possible to write a platform-neutral
description of the signals that implementers will typically want to put in
the "optional further attestations", e.g. app integrity and hardware
integrity.
I think it would also be appropriate to note in that section that
implementors should be aware that using e.g. app integrity attestations
will exclude some end users, notably those on older devices and those on
e.g. custom Android ROMs (again, in a platform-neutral language).
In addition to this, I am considering how this can be used in the OpenID
Connect Core context. I know this is not the main goal of the authors, but
I think it is worth attempting to make this compatible.
In particular, I am trying to find a way to use this to also trust an
encryption key on the device such that the OP can return encrypted JWTs.
That would allow an end-to-end encrypted channel for JWTs containing PII.
Do you know if there is any prior discussion on this? If not, I will create
a Github issue with more detail since it is unrelated to the issue
discussed in this thread.
Cheers,
Frederik
On Thu, 4 Sept 2025 at 13:54, Christian Bormann <chris.bormann=
40gmx...@dmarc.ietf.org> wrote:
> Hi Kosuke & Frederik,
>
> I do believe both Paul and I will be at IIW - happy to have a session on
> the topic and possible challenges and feedback there!
> Do you have concrete points you would like to address from an
> implementer’s perspective that haven’t been brought up in the mailing list
> or on GitHub before Frederik? Getting more implementation feedback would be
> really helpful.
>
> Best regards,
> Christian
>
> On 4. Sep 2025, at 09:18, Frederik Krogsdal Jacobsen <frederik.krogsdal=
> 40criipto....@dmarc.ietf.org> wrote:
>
> Hi Kosuke,
>
> As a potential implementer for a OpenID Connect Core use case, my
> impression is that option 1 is the best way to do it. I think it should be
> the responsibility of the Client Attester to define which risk signals
> (potentially including App Attest) they consider when determining whether
> to issue a Client Attestation JWT.
> The Authorization Server should not have to care about the exact nature of
> the "optional further attestations" (such as App Attest) provided to the
> Client Attester.
> Note also that some clients may use other attestation providers than Apple
> or Google, so adding special support for specific formats seems like a
> potentially never-ending task.
>
> We have some other doubts about how the spec can be implemented, so if you
> are considering implementation, I would like to exchange experiences.
> I will also be at IIW if you or anyone else wants to discuss further there.
>
> Cheers,
> Frederik
>
> On Wed, 3 Sept 2025 at 19:55, Paul Bastian <paul.bast...@posteo.de> wrote:
>
>> Hi Kosuke,
>>
>> the intention of the authors is option 1 ("Use App Attest only during
>> attestation generation, and rely on Keychain Services for subsequent PoP
>> JWT signing."). The main motivation for this is to have a common format and
>> mechanism across all platforms. Furthermore, the clients backend/attester
>> may have additional signals beyond Apple's app attest that are input for
>> making the decision to issue a client attestation.
>>
>> Best regards, Paul
>>
>> _______________________________________________
>> OAuth mailing list -- oauth@ietf.org
>> To unsubscribe send an email to oauth-le...@ietf.org
>>
> _______________________________________________
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
>
>
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
