Yes, the fact that getCredentialOfferURI(...) requires 2 calls (one for QR code and one for URL) and creates 2 credential offers looks like another issue, which I did not mention in the "limitations" above. I assume that ideal experience is, that the QR code shown to the user together with the URL. This is what for example walt.id is doing (See screenshot):

It would be possible to easily show both of those to the user if we switch to "required-actions" approach instead. The required-action can be ideally created by the administrator (might be the user with the credential-offer-create role, but also should possibly have a role for administering users).

In the discussion above, I've also suggested that credential offer might be created by user himself if we use the kc_action parameter, which would be added to the OIDC flow triggered by some client (See AIA docs for the details). Note that in that case, the QR code (and URL) will be still shown by Keycloak. The OIDC client, which triggered the OIDC flow, will not have any knowledge of this QR code and credential-offer and will not display it or otherwise interact with it.
Could it be the desired use-case for pre-authorization code flow for some OID4VC credentials that user himself triggers creation of OID4VC credential by himself?

No, I don't think so. The .well-known/openid-credential-issuer configuration lists vc config ids, which can be used by a user (without vc offer) to obtain a vc. This, in a way by-passes the whole credential offer mechanism (and I wonder whether it should even be supported). However, as long as it is supported, there is no need for a user to create a cred offer - because she can get the wanted vc anyway ;-) Unless of course, the Holder does not have her own oidc credentials.

Perhaps, there should be something in the vc config like "offer-required" - but that's not standard as of now. I'll check with the folks from EBSI and and also with the spec group how/whether offers should be enforced.

@tdiesler Yes, I also wonder if it should be supported to obtain VC without credential-offer.

However specifically for the pre-authorized flow, AFAIK the credential-offer is always required to be created beforehand (I might be wrong and need to doublecheck...). If that is the case, and the credential-offer creation cannot be never triggered by user himself for any specific credentials, it means that pre-authorization code flow would always require admin user involvement (user with create-credential-offer role) to create the credential for the user . So for the wallets supporting only pre-authorized flow, there would be a requirement of admin user being involved. Do I understand correctly what you mean?

Thanks @Captain-P-Goldfish for the reply. It seems to me that the use-cases you mentioned can be addressed with the "actions" approach proposed in this discussion, which would mean that we will not need credential-offer-uri endpoint entirely? Some additional points:

cross-device flow

If I understand your use-case correctly, this is exactly what could be addressed with the "actions" approach and specifically with the Application-initiated action used by Keycloak kc_action parameter.

I can see there might be still some kind of "OIDC client portal application", which is the regular browser application secured by Keycloak where user can select the verifiable credential. Once user selects the credential, the app can send the OIDC auth request to Kycloak with kc_action=create-credential-offer:eyJjcmVkZW50aWFsX2NvbmZpZ19pZCI6InBhc3Nwb3J0IiwgImNsaWVudF9pZCI6Imxpc3N5LXdhbGxldC1jbGllbnQifQ== (The parameter is Base64encoded value of { "credential_config_id":"passport", "client_id":"lissy-wallet"}) . So obtaining offer still triggered from that portal app, but actual QR code with the credential-offer shown by the Keycloak. Not by the "OIDC client portal application" itself.

This is the similar approach used for other Keycloak use-cases. For example for "update password" of the user, the built-in Keycloak account console previously used REST API where new password could be send. However this was changed to instead use "Application initiated actions" . Now account-console just redirects user to Keycloak with the kc_action=UPDATE_PASSWORD and it is Keycloak, which shows to user the form for providing new password. This has lots of benefits (EG. better security as there is no need to share the password with the client application, ability to re-authenticate user etc).

Going through the Keycloak OIDC flow also gives opportunity for other requirements - like for example if scope=passport is used, then user would be also asked to fill some additional attributes before the page with credential-offer (QR code and etc) is shown to him. As Keycloak user-profile feature allows to ask user to fill specific attributes if the specific scope=passport is used in OIDC login request. I am not 100% sure I entirely understand your use-case "user-self-initiated flow", but seems this might address it?

admin-initiated flow

I can see the proposal would work for this flow. Keycloak already has ability that administrator can assign "required action" to the user or send the email to the user like Please reset your password . The current API for this is not parameterized (which is small disadvantage in comparison to AIA, which already supports parameters). As it seems we need something like admin asking user for Please obtain VC offer of credential 'passport' with your wallet 'lissy-wallet' . However the parameterized required-actions are probably doable though by some updates to Keycloak REST API and admin console...

Marek, please take my comments as comments from someone who does not fully understand patterns Keycloak users are used to when it comes to acquring additional information.

I guess I'd like to have a QR code option be optional if it gets added directly to Keycloak.

I can imagine situations where a Quarkus based issuer application will use a credential provider that is not collocated with Keycloak the authorisation server

Cheers

I'm not sure Keycloak should be doing this work itself, sending the transaction code out of band - Keycloak does not see the user details during the preauthorized code acquisition and hence it will not know where to send the transaction code to.

I was wrong here as the access token that was acquired as part of the user login into the University website is used to access to fetch an offer from Keycloak.

However, at the time the user selects a credential to be offered, the user has already gone through the Keycloak login process and is at the University website which now will offer a QR code.

I suppose, if I go to the University website and that website shows a list of credentials before I login, then Keycloak will know at the login time the required credential... I guess the problem here is that as a user I'm in the process of the logging in into my university so I'd likely expect to be landed back at the university website first, where I'll be offered a QR code.

Though I can definitely imagine various options now. I suppose as long as the QR code is offered optionally at the KC end, all types of scenarios can be handled.

Issuer Proxy is what it is, sounds like a good term for it.

The Holder never initiates the CredentialOffer flow - like in the real world, I do not make an offer for myself, some other entity makes an offer to me.

+1, sure, I did not imply it. I mean indirectly, the holder tells the issuer (proxy) that it wants a diploma or other credential and that initiates an offer flow

The Holder never initiates the CredentialOffer flow - like in the real world, I do not make an offer for myself, some other entity makes an offer to me.

From the use-cases above made by @Captain-P-Goldfish , it looks to me that in some use-cases, user himself starts initiation of the flow (user self-initiating flow).

Right now, my understanding is, from the wallet's user's UI experience, this user scans the QR code at the University website, not at the Keycloak side.

I can imagine this QR code will be offered at the Keycloak end as well, but at the moment I'm not sure how that will work in the UI flow. IMHO that should be an optional feature.

This is where I rather see it the other way around and it would be rather Keycloak showing the QR code. I can imagine that University (which acts as Issuer Proxy in this example) provides a way for administrator to start issuing credential-offer.

Once that is done, there will be email sent to the user (or user notified by some other way) , that credential-offer was created for him. And once user clicks on the link from the email, user would be redirected to Keycloak where the page with QR code is shown to him.

The page with that QR code can be also shown to the user during regular user login (not necessarily needs to be initiated by clicking on the link from the email). And also that Keycloak page can have another button like Create transaction code . Where user clicks on that button, another email might be sent to him with the transaction code (Note there is not need for any possibly insecure hacks like sending transaction_code alongside pre-authorized code as those are not supposed to be sent together for security reasons per my understanding.)

So I am rather seeing that QR code is shown on the Keycloak page rather than on the University page. This has multiple advantages like I've mentioned in the initial post of this discussion. Also other advantage is that Keycloak page can show both QR code and the link (That would be helpful to avoid the limitation mentioned by @tdiesler : Note, there is currently a glitch in Keycloak which currently create either a credential offer uri OR credential offer QR code i.e. if you create a QR code, you effectively create another offer ).

From the @tdiesler above, I can see that picture 1 might be the "University" page (The page where admin selects which credential type to issue to which user). However the picture 2 with the actual QR code is something, which IMO should be rather shown by Keycloak.

My biggest concern here is security. As in the other scenario with QR code directly created by admin and displayed on the university page, the administrator (and university as an "Issuer proxy" client application itself) has direct access to the QR code, which in case of pre-authorized flow allows administrator to rather obtain the VC credential himself on behalf of the user.

That is why in Keycloak, there are those "Required actions" used whenever possible. For example administrator can ask user to "Hey, please setup your OTP" . And administrator asks user to setup OTP either by email or by setting "Required action" to his account . Then it's user himself, who needs to setup OTP and he can do that either during his next browser login, or by clicking on the link from the email. The page for "Setup OTP" is displayed by Keycloak to the user and administrator has never access to it. So realm administrator himself don't have a way to know the OTP secret and hence cannot login as user himself in any way. And this case actually looks similar.

I will also try to prepare a demo with the "required action" approach. Probably will not manage this year, but hopefully to share on January.

This is where I rather see it the other way around and it would be rather Keycloak showing the QR code. I can imagine that University (which acts as Issuer Proxy in this example) provides a way for administrator to start issuing credential-offer.
Once that is done, there will be email sent to the user (or user notified by some other way) , that credential-offer was created for him. And once user clicks on the link from the email, user would be redirected to Keycloak where the page with QR code is shown to him.

I think you are referring to a delayed credential issuance flow ?

And also that Keycloak page can have another button like Create transaction code . Where user clicks on that button, another email might be sent to him with the transaction code

IMHO it should definitely be done without asking a user, it should not be a choice of a user whether a wallet should request a user to enter a transaction code or not. I believe, the tx code must be generated at a time a pre-authorized code is returned and it is exactly at this time when a user is also notified out of band the tx code is available

I.e it should done by default, out of the box, whenever a credential offer is returned, with an option to turn it off for demos in the Keycloak dashboard. It is impossible to prove without a tx_code that the pre-authorized code did not get into the wrong hands

I think you are referring to a delayed credential issuance flow ?

Not sure what you exactly mean by "Delated credential issuance flow" ? In case you refer to the "Deferred credentials" described in the specification, then the answer is: No, I am not referring to that (even though supporting this might be useful as well, but that is probably rather a follow-up of initial OID4VCI support and is likely for different discussion...)

But if "Delayed" you meant that when admin creates the credential-offer for some user, then it may take some time for user (EG. few hours or days) until user can react to this, then yes. As it is natural that user may not be "online" at the same time when administrator wants to offer him some credential. I believe this is something, which both approaches (Action-based approach or current approach with custom credential-offer-uri endpoint) needs to deal with and should make sure to support it.

I've added dedicated comment with some more explanations of the flows. I hope to prototype this early next year.

IMHO it should definitely be done without asking a user, it should not be a choice of a user whether a wallet should request a user to enter a transaction code or not. I believe, the tx code must be generated at a time a pre-authorized code is returned and it is exactly at this time when a user is also notified out of band the tx code is available

Possibly yes. I am not yet 100% sure. I can imagine that it is done without asking user and transaction_code would be send automatically to the user's email. Perhaps the email can be done in the "Credential offer" endpoint (Endpoint OID4VCIssuer.getCredentialOffer in the current Keycloak codebase) where the tx_code would be sent to the user's email address.

I.e it should done by default, out of the box, whenever a credential offer is returned, with an option to turn it off for demos in the Keycloak dashboard. It is impossible to prove without a tx_code that the pre-authorized code did not get into the wrong hands

Yes, it would be great if tx_code could be sent by default. This will improve the whole security as since the tx_code would be sent to user's email, it is 100% confirmed that it is just user himself, who can do credential-request creation. It may probably help at least to mitigate at least some limitations (especially security) of the current approach with "credential-offer-uri" endpoint.

However, I am not 100% sure if Keycloak can automatically assume that tx_code is used? It is optional part of the specification and it is possible that some 3rd-party wallets don't support it.

Here is an issuer-proxy flow in my demo.

1. Alice did a few courses in the Software Credentials Academy and later visits the website to request some VCs, Software Credentials Academy looks like this:

2. Alice knows she definitely did the PQC PhD course, clicks on it, and Software Credentials Academy logs her in:

3. Software Credentials Academy talks to Keycloak's credential offer endpoint, on behalf of Alice, to create an offer for the PQC PhD and once the offer is available, itself prepares a QR code on its website:

4. Alice scans the QR code, and accepts the offer in her wallet, after entering a transaction code:

So this is how I imagine it should work, please keep in mind, at the Quarkus level there will be no guarantee Keycloak will be used as a credential issuer, Quarkus based issuer-proxy applications will have a standard credential_offer response, that is all.

So, I believe your preference is to offer a QR code at the Keycloak side. But I'm not sure how it can work, at what point in the demo above will I offer a user a QR code in Keycloak such that a user can for example cancel and just get back to Software Credentials Academy website...

In any case, @tdiesler, @mposolda, all, thanks for your work, clarifications, happy holidays, cheers

IMHO, it should work such that if you can create a credential offer, you can also see the KC generated QR code. CredentialOffer, the URI that points to it and the QR code that encodes both/either should all be part of the same KC Response.

Sure, I'd be interested to see a demo from Marek next year, see it from a Keycloak centric QR code presentation angle, perhaps different approaches can work.

There are different things that I'm trying to figure out now, how the issuer proxy knows where to redirect a wallet user to, as opposed to me hardcoding it in a demo, how a wallet can tell user that this is a credential offer from Software Credential Academy ( an entity the user just logged into a min ago), without hardcoding it, etc.

Look forward to keeping experimenting with Keycloak OID4VCI next year

Thanks again.

@sberyozkin It seems your demo is the case when "Alice" initiates creation of the credential for herself from the credential portal application (Software Credentials Academy) ? Probably similar to what I've mentioned in this comment as "user initiated flow". The difference is, that in case of the "Actions based approach", the QR code (your step 3) will be the page displayed by KC itself instead of by the "Credential portal" application.

Thanks @mposolda, one thing that might be worth accommodating for, in the user initiated flow, is for the user be able to opt out from accepting the offer and continue working with the portal after cancelling. I suppose the step 2/4 might be combined.
Look forward to discussing it further with various demos

Interesting, I thought Keycloak Credential Issuer was designed with an implicit assumption that the wallet users were Keycloak-registered users.

I might be alone with this view ;-) However, the pre-auth case suggests that KC can (and perhaps should be) placed behind some proxy that governs how and when offers are made and how they are delivered. Two other points make we wonder ...

• how would wallets even now the client_id of all the issuers they deal with?
• Is the issuer KC really expected to know the credential offer endpoints of all the user wallets?

AFAICS, working with pre-auth offers fixes many security and config issues

how would wallets even now the client_id of all the issuers they deal with?

Yes, good question, I guess a long term plan is that mobile phone wallets will act somehow similar to how public MCP OAuth2 clients act, they will get credential issuer metadata, check the authorization server content, pull authorization server metadata, register themselves dynamically with Keycloak, or via client initiated metadata...

Is the issuer KC really expected to know the credential offer endpoints of all the user wallets?

Right, I don't even know how to handle it with a single wallet :-) in a custom portal demo... I guess for the same device cases the openid-credential-offer:// scheme is designed for that ?

Yes, I also suppose that user has account in Keycloak and is able (should) authenticate to Keycloak.

From what I propose, the only possible exception to this is the flow "Admin-API initiated flow with the email". That one does not require user to have any login credentials in Keycloak (no password, passkey, OTP needed). Instead it requires him to have valid email address where Keycloak is able to send emails. In that case, user is verified by clicking the link in the email. Possession of the email address is considered as a proof that offer was used by correct user in that case.

Ok, let's assume the user has KC login credentials. Still, I maintain that the response to credential-offer-create should contain ...

• credential_offer or credential_offer_uri
• optional QR code that encodes the above

It should then be at the discretion of whoever created the offer to distribute that information to the user (somehow).
Would this simple model not work?

Let's not forget that we can limit the use of a pre-auth AccessToken to fetching the specific credential that was offered.

A non pre-auth offer made by EBSI looks like this

{
    "credential_issuer": "https://api-conformance.ebsi.eu/conformance/v3/issuer-mock",
    "credentials": [
        {
            "format": "jwt_vc",
            "types": [
                "VerifiableCredential",
                "VerifiableAttestation",
                "CTWalletSameAuthorisedInTime"
            ],
            "trust_framework": {
                "name": "ebsi",
                "type": "Accreditation",
                "uri": "TIR link towards accreditation"
            }
        }
    ],
    "grants": {
        "authorization_code": {
            "issuer_state": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImRpZDplYnNpOnpqSFpqSjRTeTdyOTJCeFh6RkdzN3FEI1Q2aVBNVy1rOE80dXdaaWQyOUd3TGUtTmpnNDBFNmpOVDdoZExwSjNaU2ciLCJ0eXAiOiJKV1QifQ.eyJpYXQiOjE3NjYxNDIyODUsImV4cCI6MTc2NjE0MjU4NSwiYXVkIjoiaHR0cHM6Ly9hcGktY29uZm9ybWFuY2UuZWJzaS5ldS9jb25mb3JtYW5jZS92My9hdXRoLW1vY2siLCJjbGllbnRfaWQiOiJkaWQ6a2V5OnoyZG16RDgxY2dQeDhWa2k3SmJ1dU1tRllyV1BnWW95dHlrVVozZXlxaHQxajlLYnBGZGp6aXVFZ005a0NCNXdvSnI2a29ldmo0UkZNVE5SWXcyNHYyNUh3SnNvaGZwTlpLR0xjM1Npc2ZRS3lCOG5odHNZcWFoNDg1eDVuRUtRcDVNdHRLZnVjZnBOblRmZGJGTWpTMnVIbzlrUHpRblBwUDhDWmZ3ZG9LemFua1lOQVEiLCJjcmVkZW50aWFsX3R5cGVzIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiVmVyaWZpYWJsZUF0dGVzdGF0aW9uIiwiQ1RXYWxsZXRTYW1lQXV0aG9yaXNlZEluVGltZSJdLCJpc3MiOiJodHRwczovL2FwaS1jb25mb3JtYW5jZS5lYnNpLmV1L2NvbmZvcm1hbmNlL3YzL2lzc3Vlci1tb2NrIiwic3ViIjoiZGlkOmtleTp6MmRtekQ4MWNnUHg4VmtpN0pidXVNbUZZcldQZ1lveXR5a1VaM2V5cWh0MWo5S2JwRmRqeml1RWdNOWtDQjV3b0pyNmtvZXZqNFJGTVROUll3MjR2MjVId0pzb2hmcE5aS0dMYzNTaXNmUUt5QjhuaHRzWXFhaDQ4NXg1bkVLUXA1TXR0S2Z1Y2ZwTm5UZmRiRk1qUzJ1SG85a1B6UW5QcFA4Q1pmd2RvS3phbmtZTkFRIn0.bhqWXbHBHNJ33DPehrt7yh8SK0yJmOQIpjJ7j9NJ40mj8b1IA4Sw-S5864KRGpM3RbcTk7UnOgoUBNvpvPsEDQ"
        }
    }
}

one made by KC like this ...

{
    "credential_issuer": "http://localhost:8080/realms/oid4vci",
    "credential_configuration_ids": [
        "CTWalletSameAuthorisedInTime"
    ]
}

Ignoring trust framework and issuer state, they essentially offer a credential of given configuration that can be found in the Issuer's metadata. Note, EBSI still uses Draft11 - an older version of the spec

I also wonder what to make of this, even without the offer anyone can access the issuer's metadata and then ...

• send and AuthorizationRequest to get an auth code
• exchange the auth code for an AccessToken
• send a CredentialRequest using the scope references by the credential_config_id

No offer would ever be needed, which makes me wonder what it is good for in the first place?

One possible solution to this bypass, would be to somehow mark a credential_configuration as "offer required". In such case, the Issuer could reject the CredentialRequest when there is no CredentialOfferState for it - but that is not in the spec.

Here is the cred offer matrix that was considered

Thanks, indeed I see in the spec that in this case the wallet is supposed to figure it out itself which grant to use

No offer would ever be needed, which makes me wonder what it is good for in the first place?

This is probably related to another flow, where the Wallet user does not start with the Issuer (proxy) portal but with the verifier portal that requests a user to submit a credential, in my demo it goes like this:

1. Alice looking for a new software job and finds Best Software Company that accepts digital credentials:

2. Alice knows she became a Java Coder Champion recently so she selects a Java Coder Champion, and Best Software Company prepares a credential request screen with a QR code, this now goes the OpenID4VP route:

3. Alice is still at the Best Software Company website, and scans the QR code with her Wallet that gives control to her Wallet, Wallet logs Alice in:

(Wallet might login Alice in some other way, just a demo wallet is directly protected by Keycloak)

4. Next, Wallet tells Alice that the request credential is not available in her wallet and asks if she'd like to download it:

5. Now, Wallet redirects Alice to Keycloak requesting a required credential scope, using the authorization code flow - as per your description, and accesses the Keycloak to pull the credential:

and now Alice can choose what to submit/disclose to the verifier