@thomasdarimont @babisRoutis Could we please create a GitHub issue for this?

Hi

Created #43136

Can the attestation based client authentication also use identity providers in similar way like client-auth-federated ? Would it work with OID4VCI HAIP testsuite?

Yes, that should work. Currently, it works such that an RSA-P256 key-pair with X5C Certificate is externally generated and then added to the these suite configuration, like this ...

        "client_attester_keys_jwks": {
            "keys": [
                {
                    "kty": "RSA",
                    "kid": "openid-abca-attester-key",
                    "use": "sig",
                    "alg": "PS256",
                    "n": "q1Lixv3MJtq8HfIiiINrqnx4co2In0keBxJDWfO0ssmu6w7SOO5y4eeI-y8_y6XXYD_k-TtD24RsnmCW1xdQ5gRpcGBrvBG3A35Qm6el1jLab3Bu23vicykji8vX1L-ICMpFH142erKJuy8Ko4mYbZTZiiYQBOcCIYtskuHHtoel0SIyDzhENyU69N3RYYGtnuGgf7pTJGHty0OQDpUaLhFyTJZ4voWq_X1QeM617VLRcSt9IyBTxYq7tNVurIdyAdEKMGHL8Fpur7mF-paPqj7KBtvTawHOQDOlEG253kT8AK-QqtWPw0grAI8TJYsVhsf88gn6h4ss5pC7aMGQmw",
                    "e": "AQAB",
                    "d": "QnX_emF3YnVFN7q4UcvlpvftQ8cLAnu7VdPsY8dKSHc7z3zq6WH7GA6ZUZP1RBucLv7qZRLsEorPFitzKJKnc-uvOYR2FrmqjQTh4VhKWYtVuJhdsPBgmvsRCoizvBjm_T32TaJfMP70tjQcBO_6PTxanaCBY114MqojHuHOd0yJm4QXum0p5lgAdKbhzNOo-E6CSI5ym5lVo0GgakXOz0Kc69i7MoIEgWP-vkVS5CBAOtwLLaIW_jAxXhZwcfNuH-BduunZIsdv5eZRO_f8k9zGB96h4IhcUmEro-aXdQRIzfjSYJIjVBSEarMSQOcMp4osOYhQ1XguSlIn5YrjwQ",
                    "p": "vPv5F9R1ndBi8WRIfISHSzdA_d3lCBLnnrnR47H7r682iW5cREGNe7VpEY640CYgAK6xDW8ZwPPKmjBM0QUXudZ8D0xAq2nhTN6Z6UuNud996QPBr9C9v9mu5yDoymXaQChRL8feOiE473NERWp-sQiY2o6TMgra5wNmPppdGts",
                    "q": "6BOwjcvOc_-zCguZG6bTOfiq7OIozBzNKajI6b2r23lJmdqM7Ma--Ff9IADtZtk3X5K9zOdusz12Fbk9LOXSoW84WLhhytp02xiPEGntA0mE11GgelGeGoGrubsdnAYi-IVdeUabpLIqxw57p-pKhTPZLI0yQcz08upQ2EUT7UE",
                    "dp": "ECPA0T0u0kyCtrTmz-ONnmnYnhW-QqNCrraV60k_AnEHSlNng9jJWYBTudEjjXtEDmrc6hXL8EOh0OtBFDTIIvHjZHcRqtH_EM6N_HOcZfxlR2ovt3EvU1wm6MxRtT9flU0cKeV64CIIN8LzWK5QpZPjYf79KS_uI_6RU9VhEDM",
                    "dq": "pafIUq6zw2E1r2nv9Cj0hWDWwRf9_xRf7eio4Q-eaJ7-xm-WQDzte99yszF2Q_-w4uufx287OX4ZmBANdsrluo3lLo8OXvnoh6vUEudJYxtLU1bUsfsoW8tLhNvnmsNWmwa3XiXkW39Bway433cBkmscDg0LXqSqA-r1oipMuwE",
                    "qi": "Ae_t1NeK5FWZKwcDVBWckbZlcXKK45pLmuVo21K79SHi3PykZbS4WA0Pv8Rtmg7OLZj-QKoQcRlI4WYgoY9hUez-V1oe1w2KD44e3IRwxVYvfCrHx1I7VHYP-TKmE-jXOIdtvLHLKB9QtRI1fztyaTQ3_gZZ_Az78eYKobpKUCs",
                    "x5c": [
                        "MIIDIjCCAdagAwIBAgIGAZ1xd6DUMEEGCSqGSIb3DQEBCjA0oA8wDQYJYIZIAWUDBAIBBQChHDAaBgkqhkiG9w0BAQgwDQYJYIZIAWUDBAIBBQCiAwIBIDAeMRwwGgYDVQQDDBNnaXRodWIuY29tL2tleWNsb2FrMB4XDTI2MDQwOTA4NTkxOFoXDTM2MDQwNjA4NTkxOFowHjEcMBoGA1UEAwwTZ2l0aHViLmNvbS9rZXljbG9hazCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKtS4sb9zCbavB3yIoiDa6p8eHKNiJ9JHgcSQ1nztLLJrusO0jjucuHniPsvP8ul12A/5Pk7Q9uEbJ5gltcXUOYEaXBga7wRtwN+UJunpdYy2m9wbtt74nMpI4vL19S/iAjKRR9eNnqyibsvCqOJmG2U2YomEATnAiGLbJLhx7aHpdEiMg84RDclOvTd0WGBrZ7hoH+6UyRh7ctDkA6VGi4RckyWeL6Fqv19UHjOte1S0XErfSMgU8WKu7TVbqyHcgHRCjBhy/Babq+5hfqWj6o+ygbb02sBzkAzpRBtud5E/ACvkKrVj8NIKwCPEyWLFYbH/PIJ+oeLLOaQu2jBkJsCAwEAATBBBgkqhkiG9w0BAQowNKAPMA0GCWCGSAFlAwQCAQUAoRwwGgYJKoZIhvcNAQEIMA0GCWCGSAFlAwQCAQUAogMCASADggEBAImAY92qFQeLpL9n6S7HHpLxLNoE6LE+5mpUUJM/tc2+TJ8xx2cpdzHohTAozwTuAYgmH5XlTH79ra2UlXrtNVvSKl5Ae+aByRCqRs/sKdwl5gdGW6eMwlLdkg4peKuGIG2j5ud7Pg29LrbRA88cIpzIcKr6JumS13eQ3AQKsB6xjxgv0KmQrDd7kBUb7hmedLYWLn/SEmpLiftIPOQM8oWJF0erFT5otZ0KlmTLstyM1yoEX6RpYc3rP0cbcCDA20PQQAX/fO/1MS7+Q23Rg7goSSsL0gZPSjiPcowd/dcFqsFkZ/KElrM1MJjccLJF/egUE4VjtLvrHMRe3tGtX/s="
                    ]
                }
            ]
        },

We then reduce that to public keys (just one for now) and add it to the AttestationBasedClientAuthenticator config.

i.e. currently it can be done via Admin UI and kcadm like scripted here

no 'issuer' in the OAuth-Client-Attestation JWT

I'm not an expert ... is it really necessary to disclose the identity of the attester in the Attestation JWT? It is a signed JWT and the Issuer can iterate over the public keys from the attesters it trusts. If the signature matches one one of them, the Attestation JWT was signed by a trusted attester.

However, Draft-07 (i.e. the one that we are currently bound by) has this section ...

The following content applies to the JWT Claims Set:

iss: REQUIRED. The iss (issuer) claim MUST contains a unique identifier for the entity that issued the JWT. In the absence of an application profile specifying otherwise, compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of [RFC3986].

... and the current implementation checks just that

        TokenVerifier.Predicate<JsonWebToken> issCheck = (t) -> {
            if (Strings.isEmpty(t.getIssuer()))
                throw new TokenVerificationException(t, "The iss (issuer) claim MUST contains a unique identifier for the entity that issued the JWT");
            return true;
        };

There is no such requirement in Draft-08

Related issue/discussion - openid/OpenID4VC-HAIP#352

Dear @VinodAnandan

In the context of EUDIW, it is required that the Client Attestation JWT ( the term used by ARF is Wallet Instance Attestation, aka WIA), includes an x5c to its protected header. This chain will be used to identify whether the Client Attestation JWT can be trusted or not.

An auhorization server would have to

• validate the certificate chain against a "List of Trusted Entities" (defined per ETSI TS 119 602, annex E, Wallet Providers List)
• validate the end-entity certificate of the attester (Wallet Provider)
• proceed with the normal validation of Client Attestation JWT and its PoP
• finally, especially for ABCA on the token endpoint, add to the issued access_token a EUDIW-specific claim, found to the Client Attestation JWT named client_status

So in the EUDIW case, retrieving or configuring JWKs is not an option.

Instead, a specific List Of Trusted Entities (Wallet Providers List, to be more precise) must be taken into account. If you are interested more on this, you can check here

What does this mean for Keycloak?

Unfortunately, I am not aware of Keycloak's internals.

I can only recommend the use of an abstraction (like an interface) that would take into account the Client Attestation JWT and would return the public key, with which the client attestation jwt's signature will be validated.

Such an interface may have multiple implementations:

• Use a JWKs configured on the Keycloak (with the keys of the trusted attesters)
• Use a Keystore configured on the Keycloak (with the certs of the trusted attesters)
• Use some other means (like a List Of trusted entities)
• etc

I hope that I am not confusing you 😄

@tdiesler In my opinion, it is essential to implement a strong/robust chain-of-trust validation mechanism to mitigate the risk of misuse. Provided that a received attestation can be reliably verified without introducing opportunities for origin spoofing or attacker manipulation, the approach should remain secure.

As @babisRoutis highlighted, there maybe multiple scenarios. Perhaps it would be worthwhile to consider these scenarios as part of the implementation. What are your thoughts @tdiesler ?

I think we need to get started somewhere - currently there is the ootb mechanism of providing the AttestationBasedClientAuthenticator with a config that atm contains known attester keys. This mechanism can of course be swapped out for something else. I noticed for example that there is a similar need for known public keys with key 'attestation' proofs - it uses a three layer lookup mechanism that can read the known keys from realm attributes. This could be one candidate for a unified key discovery mechanism.

However, first we need the initial implementation in place so that it can provide the stage for qualified feedback i.e. folks must be able to try it in order to comment on it