OpenID for VCI, consider client credentials grant

[Nikos Fotiou]

I believe the client credentials grant (section 4.4 in OAuth2 RFC - https://datatracker.ietf.org/doc/html/rfc6749#section-4.4 ) fits nicely with this use case: users can configure an issuer with, for example, a username and a password for their wallet and then the wallet can receive the VC. This approach has the following advantages:

• It is easier to integrate new wallets: new wallet implementations do not have to perform a "registration" process with the issuer, instead users individually are responsible for creating the "client credentials" for their wallet with the issuer.
• It is faster, since it is  requires one roadtrip less, compared to the authorization code grant.

‌

[Torsten Lodderstedt]

First of all, issuers can offer other grant types beyond what is mentioned in the spec. Here is the respective text:

Deployments can use any pre-existing OAuth grant type and response type in conjunction with this specifications to support those scenarios in the context of different deployment architectures.

To your concrete proposal: The client credential flow requires the AS/Issuer to know the client. Te me it sounds like you want to use the password credential flow, which is deprecated for security reasons.

[Nikos Fotiou]

With respect to your comment issuers can offer other grant types beyond what is mentioned in the spec I understand that it is written in the spec, but the specs are written assuming only the authorization code grant. For example, section 6.5.2 says

A credential authorization request is an OAuth Authorization request as defined in section 4.1.1 of [RFC6749]

Equally important, the client credential grants does not have an “authorization request” step (see https://www.rfc-editor.org/rfc/rfc6749.html#section-4.4.1), but this spec not only assume that there is such step but also they extend this step to include the authorization_details field (section 6.5.2).

Similarly, in section 7, if client credential grant is used, there is no need for having a “pre-authorized_code”. Finally, with client credentials grant, PKCE is not required.

In summary, to my view, the way this spec evolves it precludes client credential grant.

With respect to your comment the client credential flow requires the AS/Issuer to know the client :

In the authorization code grant, used in the spec, also the AS/Issuer needs to know the client/wallet; in the authorization code grant this is done either out-of-band or using dynamic client registration. There is a significant difference however. Suppose a wallet used for storing VCs that represent University Credentials.

• With the authorization code grant flow the wallet “provider” must register with every (university owned) VC issuer (in order to obtain “client_id” and “client_secret”)
• With the client credential grant flow each user owned “instance” of the wallet must register with the VC issuer with which it will be used (in order to obtain “client authentication” information). This can be easily done by each student. It can even be done using OAuth 2.0 Dynamic Client Registration Protocol (https://datatracker.ietf.org/doc/html/rfc7591#section-2)

I want also to highlight that client credential grant does not include re-directions, which solves many issues related to this and the OP4VP specs (e.g., using multiple wallets in the same device).

‌

[Tom Jones]

The idea seems to be indistinguishable from issuer updates to creds in the holders wallet. That might be a better way to provision this feature. Passwords are by far the worst option, it gives the issuer too much privilege.

[Oliver Terbu]

@Nikos Fotiou If client credentials grant was used, how would the issuer know what data should be put into the credentials to be issued? Client credentials is not really linked to a user or a session. Furthermore, client credentials grant is not a substitution for PKCE. PKCE is mostly used with mobile and public clients. Putting the client credentials into the native app leads to security issues since those secrets can be extracted. As Torsten pointed out, password credential flow is deprecated.

Can you describe your issuance process and we might be able to advise.

[Nikos Fotiou]

To begin with, you cannot put client credentials into the native app, it should be different credentials per app instance. Secondly, PKCE is not required with client credentials grant, since everything takes place in the “back channel” and no interaction takes place through the user browser, i.e., steps 2 and 3 in Figure 1 here are not required https://www.rfc-editor.org/rfc/rfc7636 Finally, client credentials can be easily linked to a user, for a example a user can provide “out of band” to an issuer the client credential that will be used by her wallet. We have used client credentials grant for issuing VCs to IoT devices. Each IoT device is configured with a public key, which is used as the “client credential grant”. An authorized user then configures the issuer with the VC that should be issued per public key. You can also think a hotel use case where the client is the mobile application of a hotel and the VC is used for opening the door of a room: the hotel can configure to the issuer that a specific app instance has access to a key and then, at some point in the future, the app instance will request the key using oauth2 with client credentials grant. Finally, client credentials grant and password credential flow are not the same. Client credential grant is secure and it is supported by major IdPs (okta, google, amazon, and other)

[Nikos Fotiou]

I would like to come back to this. I realized that client-credentials grant flow is almost the same as “pre-authorization” code flow with the only difference that the grant is provided to the wallet “out-of-band”. Here is how pre-authorization code flow could have been implemented a-la client credentials grant. Note that using this approach pre-authorization code replay is not possible!

In this sequence diagram if you rename “pre-authorization code” to “client credentials” you have vanilla OAuth2 client credentials grant flow.

[Kristina Yasuda]

pre-auth code is different from client credentials used to authenticate the client. The only similarity is that Authorization Endpoint is not used.

Note that using this approach pre-authorization code replay is not possible!

Wouldn’t this require Credential Issuer also authenticating the client/wallet at step 1, which in many cases is not possible and would limit the use-cases. End-User is uploading the necessary pdfs to the issuer’s web app in step 1 - how can the issuer authenticate the client/wallet?

not sure how the sequence diagram above is vanilla client credentials grant

‌

[Nikos Fotiou]

Wouldn’t this require Credential Issuer also authenticating the client/wallet at step 1

Why are you saying that? It is the user that configures in the client/wallet credentials at step 1 without the client involvement. At least in OAuth2 landscape this is a standard business practice, e.g., in Azure B2C active directory, in auth0 platform, in amazon cognito.

not sure how the sequence diagram above is vanilla client credentials grant

I am referring to step 4 of the diagram I posted.

[Kristina Yasuda]

i think you are misunderstanding step 1 - user does not configure the client/wallet credential at step 1, user provides proofing/identification information to the issuer.

[Nikos Fotiou]

Here is a “cleaner” version. How steps 1,2,3 are implemented is left as a design choice.

‌

And here is a use case:
”An end user wishes to store in her NFC-enabled university card (used as a wallet) a VC that gives her access to the a lab during night. She logs in to the university web-based system, provides all necessary documentation, and she receives a pre-authorization code. She uses her phone to configure the smart card with the pre-authorization code. The next day the VC is ready, she visits her university, and she touches with her smart card a terminal located outside the lab. The terminal makes a credential offer and the card responds with a token request + the pre-authorization code ….”

I understand that the use case is not the the optimal as communication should take place over https, but I guess you understand the concept: the wallet is a device, or a machine, or a service process, etc.

[Kristina Yasuda]

Client Credentials Grant is defined as “The client can request an access token using only its client credentials (or other supported means of authentication)”.

In Pre-Auth Code Grant, the client cannot be request access token using only its client credentials - it also needs to send a pre-auth code.

Hence Client Credentials Grant and Pre-Auth Grant are different and OID4VCI uses Pre-Auth Grant.

[Nikos Fotiou]

Sorry if I have got it wrong, but in Pre-Auth Grant the only means of client authentication is the pre-authorized_code (and optionally the pin), isn’t it? In any case this definition discussion can be endless. The main issue remains, OID4VCI says:

Upon receiving a successful Authorization Response, a Token Request is made as defined in Section 4.1.3 of [RFC6749].

This excludes the client credentials grant, which is useful for many use cases. So I propose either modify the text as follows:

Upon receiving a successful Authorization Response, or any other valid Authorization grant, a Token request is made

Or add a variant where the pre-authorization code is sent to the user and not the wallet (as the sequence diagram I posted in the previous message).

[Kristina Yasuda]

pre-auth code authenticates the user, not the client/wallet.

you can use client authentication at the token endpoint with pre-auth code grant.

[Kristina Yasuda]

Or add a variant where the pre-authorization code is sent to the user and not the wallet (as the sequence diagram I posted in the previous message).

credential offer including pre-auth code can be sent directly to the user (physical mail) etc.

[Nikos Fotiou]

credential offer including pre-auth code can be sent directly to the user (physical mail) etc.

That’s interesting. So, supposedly a user wants to store a credential to an IoT device. The following sequence of steps is valid?

• User provides all necessary information to the issuer
• The issuer creates a “credential offer” in the form of a link and somehow presents it to the user
• The user configures the IoT device with the “credential offer”
• The IoT device makes a token request

If it is valid I guess it would work for our use cases.

‌

[Kristina Yasuda]

yeap, that understanding is correct.

can an IoT device fulfill this requirement?

The Credential Issuer sends Credential Offer as an HTTP GET request or an HTTP redirect to the Credential Offer Endpoint URL (of the Wallet) defined in Section 10.1.

or does it have to be relaxed to meet your use-case?

‌

[Nikos Fotiou]

For our use cases this is fine.

[Kristina Yasuda]

great! resolving.