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...

@Captain-P-Goldfish

@francis-pouatcha this is the point where I disagree with you. If I understood you correctly in todays meeting you said that the credential-offer might be issued by the client. But I do not know how this should work and I think that the explained use-case is the intended one for the credential-offer. If the client should be able to issue the credential_offer it must have a strong trust-binding to Keycloak. Maybe this would be an idea when using the PushedAuthorizationRequest. The credential-provider could send the credential to Keycloak creating a transient user and then returning a preAuthorizedCode. But the better way would still be to just follow the standard AuthorizationCodeFlow and show the QR code at Keycloak instead of the clients website.

I think you got me wrong. I mean the OAuth client could get the credential offer and present it to the wallet.

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.

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.

Hi @mposolda

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.

I guess there should an option in Keycloak dashboard to turn a tx_code generation off for such cases. However, given a sensitivity of leaking the preauthorized code where you get a long time VC, may be it should be treated as an opinionated decision, where it would be up to such wallets to enhance their credential offer acceptance screens if they want to work with Keycloak.

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

Thank you, everyone, for these rich contributions. From my perspective, it greatly helps to have this summary of the possible flows we would like to support, classified into either initiated by an Admin or a target User themself.

New Keycloak OpenID4VCI views should be customizable

My comment is first to endorse the move to a Keycloak-controlled experience. In addition to being more spec-aligned, the proposal encourages a unified use of Keycloak as an OpenID4VCI Issuer. Eventually, the Issuer Proxy is simply discharged from OpenID4VCI operations by redirecting back to Keycloak via the kc_action mechanism and passing relevant parameters. However, as raised by @Captain-P-Goldfish, I would like to second the point that the look and feel of the Keycloak views should remain open to customization. This is much needed to satisfy business requirements.

We value the User-initiated flow

Despite understandable criticisms pushing for a total alignment with the “Admin creates offers for Users” narrative, I do not believe letting Users self-request offers is that much in contradiction with the spec. In the end, it is still the Issuer delivering offers, and that can be seen as an Issuer policy to offer credentials for all users. In the worst case, my feature request is to leave support for user-initiated flows configurable. Admin-initiated flows would be very impractical for our use case, where we essentially need Identity Credentials.

Let’s clarify the place of the authorization code flow

In the three flows outlined, two make use of the kc_action mechanism. Is my understanding correct that the OpenID4VCI authorization code flow would be redundant in those flows? Do we have a comparable mechanism that would not require user authentication prior to displaying a QR code?

More examples would be useful for Admin-initiated flows

I seize that the purpose is to remain open and flexible regarding how an offer is delivered by an admin to a target user, but it would be great to gather concrete implementation ideas. In this discussion, I could note two approaches:

• Define as a Required Action and deliver to user on next login
• Send an email out of band to target users

I sense both to be somehow problematic.

• Being greeted by an unexpected “Required Action” after logging in for some other purpose is not great for UX, and even harder to swallow for non security-critical operations such as retrieving a credential.
• Sending emails may not be accessible to low-budget organizations.

I would appreciate additional ideas for alternative approaches for admin-initiated flows. Maybe a link to share?

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.

Actually, there are indeed use cases in which the user has no Keycloak account. The currently most common use case for us is the PID credential flow. We are issuing PIDs (Personal Identifiers) based on German eID cards. The user is delegated to Keycloak and selects the eID provider. This triggers an authentication process with the eID server, which eventually creates a transient user in Keycloak, from which we then build the credential.

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

Thanks so much @Captain-P-Goldfish, appreciate the structured way of the feedback presentation.

The open question (and currently out of scope for OID4VCI) is how credential data is provisioned or asserted from the university to Keycloak.

I suppose that will happen as part of some customer onboarding process, realm related setup etc.

A dedicated login theme is assigned to that client (which Keycloak already supports).
That client-specific theme can provide the UI where the Credential Offer (deep link / QR code) is presented.

Sounds good, I might ask my Keycloak friends to help with that, how to set it up.

IMHO, what will really help the community, is for Keycloak to ship (or host in its VC repository) that kind of demo, that would emulate a real business case, a university diploma case.

One comment,

The university can influence the user-facing experience (e.g. branding) only through configuration provided to Keycloak, such as client-specific login themes.

So this assumes then that offers can only be presented precisely at the login time - will it work in practice though ? I certainly can see how it works when:

• a user gets a delayed credential offer uri by email
• a user goes to the university website and immediately sees a credential offer URI, before logging in

I'm thinking about a case where I go to my medical clinic website, surely I have to login first, I may have 50 types of medical certificates, and once I login, I can browse through a list of verifiable credentials, like I did that op 2 years ago, did that blood test last week, and have a credential offer flow starting only then...

Or the same University case which has 50 types of courses, Oxford, etc. Is University going to offer all 50 offer URIs for everyone to choose their specific course before logging in ?

Do you see what I mean, these are kind of questions I'm concerned about...

Cheers

@Captain-P-Goldfish @sberyozkin Sorry for late response.

In many real-world deployments, organizations such as universities will neither implement OID4VCI themselves nor operate issuance endpoints directly. Instead, they will rely on a dedicated identity infrastructure component (e.g. Keycloak) that they have a trust relationship with.

+1 for this. Ideal is, if universities don't need to implement much of OID4VCI logic as well as custom logic (EG. calling custom REST endpoints and implementing the custom logic to transfer the credential-offer created by administrator to be shared with the user ).

From a user-experience perspective, the issuance flow can still start on the university website.

One possible approach is:

The university is registered as an OpenID Client in Keycloak.
A dedicated login theme is assigned to that client (which Keycloak already supports).
That client-specific theme can provide the UI where the Credential Offer (deep link / QR code) is presented.

This allows:

a university-branded user experience, and
a clear and spec-compliant separation of protocol responsibilities.

In this model, the Credential Offer is generated and served by the OID4VCI Credential Issuer (Keycloak).

If I understand correctly, if we have the "Actions" approach (in particular AIA) as I am suggesting in this discussion, then you will not need any custom client-specific theme as the page with credential offer (deep link / QR code) can be displayed to the user by Keycloak.

The only thing needed might be that university will trigger OIDC authorization request with additional parameter like for example kc_action=create-offer:university-credential . This will redirect from university to Keycloak, and on the Keycloak side, it can display the page with deep-link / QR code.

If I understand correctly, if you need university-branded user experience, then custom theme might be needed. But in this theme, you will possibly need to implement just CSS (not custom logic to display QR-code or link).

I'm thinking about a case where I go to my medical clinic website, surely I have to login first, I may have 50 types of medical certificates, and once I login, I can browse through a list of verifiable credentials, like I did that op 2 years ago, did that blood test last week, and have a credential offer flow starting only then...

This use-case should be possible with the "actions" based approach. When university wants to display medical certificates just to authenticated users, it can redirect user to login to Keycloak first by normal OIDC authorization_code flow (classic login flow). Then once user is logged, it can display the medical certificates. Once clicks on some of them, there will be another OIDC redirect to Keycloak, but now with kc_action parameter added. Keycloak will skip login screens due the existing SSO, but will just display the screen with the credential offer (QR-code etc).

The same flow is used for example by Keycloak account console. You can try for example to open account console at the URL like http://localhost:8080/realms/master/account and on the page with user credentials, you can click for example on reset password. You are redirected to Keycloak now and there is SSO flow triggered under the covers, but user sees just the page where he is asked to update-password. More on AIA in the Keycloak docs.

I'm thinking about a case where I go to my medical clinic website, surely I have to login first, I may have 50 types of medical >>certificates, and once I login, I can browse through a list of verifiable credentials, like I did that op 2 years ago, did that blood >>test last week, and have a credential offer flow starting only then...

This use-case should be possible with the "actions" based approach. When university wants to display medical certificates just to >authenticated users, it can redirect user to login to Keycloak first by normal OIDC authorization_code flow (classic login flow). >Then once user is logged, it can display the medical certificates. Once clicks on some of them, there will be another OIDC >redirect to Keycloak, but now with kc_action parameter added. Keycloak will skip login screens due the existing SSO, but will just >display the screen with the credential offer (QR-code etc).

This is what I do for a wallet initiated flow, where I start a new redirect for any new credential request or when the wallet lists some well-known credential types.

The problem with kc_action parameter is that it does not interoperate at the Quarkus level, though perhaps we can let provider specific customizations, it might work.

In any case, for whatever it is worth, I'd like to suggest that we can experiment with both Software Credential Issuer and Software Credential Verifier, as well as Software Credential Wallet and use it as a test application that attempts to emulate an every day issuer holder verifier setup beyond specialized EU or other government sponsored projects, so that someone who creates, for ex, a secured Quarkus REST endpoint that accepts bearer access tokens can instead accept VPs (as Software Credentials Verifier will strive to do) or add a credential issuer capability to their university website, similarly to how Software Credentials Issuer will do it.

I'll attempt to push it to a Quarkiverse extension in a few weeks or months and ping you to discuss. Np at all if you'll consider something else to experiment with, thanks

The "playground" to experiment with can be nice. As you know, there is also this playground https://github.com/keycloak/keycloak-playground/blob/main/fapi-playground/README.md#oid4vci-demo , but this is more low-level (showing HTTP requests/responses etc) rather than demo suitable for the "end user experience" .

@mposolda The Keycloak OID4VCI playground is very useful for sure.

I'd like to briefly return to

This use-case should be possible with the "actions" based approach. When university wants to display medical certificates just to authenticated users, it can redirect user to login to Keycloak first by normal OIDC authorization_code flow (classic login flow). Then once user is logged, it can display the medical certificates. Once clicks on some of them, there will be another OIDC redirect to Keycloak, but now with kc_action parameter added. Keycloak will skip login screens due the existing SSO, but will just display the screen with the credential offer (QR-code etc).

How will it work with pre-authorized codes since, I'm assuming subsequent redirects are authorization code flow redirects ?

It is also not clear to me how an opt-out works in this case, where a user cancels an offer, before the control goes to the wallet.

Unfortunately, I don't have an experience in customizing Keycloak screens and actions, so it is rather hard for me to visualize.

If you could prepare some screens in the next few weeks or months it would help, or perhaps we can have a look at my demo together at some point and see how an issuer proxy (or intermediary ?) like a software credentials academy can handle it

@tdiesler It could be great if we can simplify, but at the same time, it could be good to address the most needed use-cases with good user experience.

It seems to me that admin REST API based approach would have still a lot of limitations as I've outlined in the initial post of this discussion. Some of them could be likely addressed, but likely not all... Especially, it seems to me that REST API based approach with custom credentail-offer-uri endpoint cannot address most of the use-cases mentioned in the other discussion by @Captain-P-Goldfish where the page with QR-code / deep-link is supposed to be displayed by KC itself.

Just a note: It seems to me that AIA (actions based approach) is not silver bullet to everything. If there is really hard requirement, that Issuer portal (EG. university) is required to display QR-code / deep-link directly on it's site, then custom REST endpoint would be still needed. I hope we can avoid this if possible (especially considering security etc), but not 100% sure we can avoid this entirely...

If not, maybe we need both REST endpoint and "Actions based approach", which would allow to display credential-offer page by Keycloak itself.

University makes credential offers to 1000+ students

This would not be a problem (in the "actions" based approach) as Keycloak admin REST API allows to create required-actions either with the admin console or by calling admin REST API directly. It should be possible to have requests to create required-action for 1000+ students. That would in fact allow bulk-creation of credential offers for the users.

Event agency issues tickets without even needing an account for each ticket holder

The support for the use-case where user doesn't exists in Keycloak, is not supported right now as Keycloak always needs user account. But as I can see, this is also not supported in current credential-offer-uri endpoint as it always expects existing user to exists: https://github.com/keycloak/keycloak/blob/26.5.2/services/src/main/java/org/keycloak/protocol/oid4vc/issuance/OID4VCIssuerEndpoint.java#L413 . There is the notion in Keycloak of "temporary users" (aka transient users), which are supported by workflows feature, but that feature is not supported yet.

BTW, there was this idea that the /create_credential_offer endpoint does create the credential offer and returns nothing. Through some other endpoint or in the UI the state of that credential offer could be shown, communicated, etc. We dismissed this idea, because it does not fix anything but simply delegates a potential vulnerability to some other endpoint.

I was thinking about something similar as well and added some details in this comment (See 2.b in particular). That would be some improvement of REST API based approach. Would that one work for your use-cases?

Yeah... Also there is not the distinction in specs between "Issuer" and "Issuer portal" (or "data holder") as mentioned by Pascal in that other discussion in the specs. It gives some freedom, but freedom often means possibility for issues and security vulnerabilities... ;-)

@tdiesler Narrowing scope of the access-token can be nice, but still not so great protection. Some microservices (which do not call OAuth2 introspection endpoint and do not properly check audience or roles of the accessToken, but just verifying signature) might still treat it as regular access-token even though it was access-token obtained by the "admin" and not by user himself.

Could be great if we can make sure if access-token returned from pre-auth flow can be really available just to the proper user and not to the "admin" user . Just cross-posting for the reference some additional thoughts how to ensure that (Especially see approach 2)

It should not matter wether external services introspect the token or not. When used as a bearer token in a request to Keycloak, it would not work for anything else but a credential request for the existing credential offer that it references. Or is there perhaps another angle that I'm not seeing?

Some microservices, which receive access-token from other parties, may not use access-token at all to do any requests to Keycloak.

Usually, when microservice obtains access-token, it can do OAuth introspection request to Keycloak with the access-token to ask Keycloak if access-token is valid. However microservice may not do that. Some microservices rely on the fact that Keycloak access-token is JWT and they just verify the signature on the access-token (Service has access to Keycloak public keys as they can be obtained from Keycloak JWKS URL, so service is able to verify signature on the access-token with corresponding Keycloak public key). Some services may not properly check aud claim or roles in the token, but just checking the sub claim (or preferred_username) to check if access-token was issued to the expected user.

If administrator (guy with create-credential-offer role) has a way to obtain access-token issued to other user (which is currently possible with pre-authorized code grant), it gives him permission to access such microservice.

Does it? An AccessToken redeemed from a pre-authorized code grants access to the /credential endpoint for a specific credential offer - it should otherwise be useless.

Yeah, agree that access-token obtained from pre-authorized grant ideally should be useless (with only exception being to call /credential endpoint). But currently that access-token obtained from pre-authorization grant is not useless. At least right now, it is regular Keycloak access-token, which can be used for anything (accessing any microservice, or admin REST API or whatever...). That is what whole issue #44745 is about though...