[OID4VCI] client_id for anonymous Clients

[David W Chadwick]

There is no client id in the pre-authorised request to the token endpoint. Yet in the request to the credential issuing endpoint a client id has to be specified (in the iss of the jwt of the proof).

This could be resolved by saying that the iss can be set to a random value when the pre-authorised flow is being used. However if we require a pre-registered client id to be used, then we could add this to the initiate issuance request and give it to the wallet in this way.

[David W Chadwick]

A related issue is that our OAuth2 server will not give a refresh token to any client that does not have a client id. So currently with the pre-authorised flow our wallets can only obtain an access token from the token endpoint. This is bad, since when the access token expires the user will have to go through the whole pre-authorisation flow again. So adding the client id to the initiate issuance request would kill two birds with one stone i.e. allow the Oauth2 server to refurn a refresh token to the wallet, and allow the wallet to use its client id for the iss of the jwt-proof.

[David W Chadwick]

PR#329 is a resolution of this issue

[Torsten Lodderstedt]

The client_id (and client authentication data) is required at the token endpoint for a reason. That is to identify and authenticate a client (meaning a service or software) and apply a policy to it. That may include legit redirect URIs, allowed scope values, data to be shown in the user consent, …. And RFC 6749 also requires the AS to bind any refresh token to the client id and authenticate confidential clients when they use the refresh token to prevent token theft.

Issuing a client id in the pre-authz code flow does not adhere to these concepts.

In pre-authz code flow, like any other OAuth flow, the client needs to establish its client id in advance. There are various existing mechanisms to do so:

• manual registration (might also include vetting of the party)
• dynamic client registration
• OpenID Connect Federation

Perhaps even TRAIN could be used.

I would like to understand your requirements in order to come up with an idea which way would be best suited.

[David W Chadwick]

The requirements are rather simple. A user with a wallet, who has a relationship with an issuer (e.g. they have been awarded a certificate by the issuer) has logged into the issuer’s web site and has been invited to download the VC into their wallet. This should be as simple as possible from the user’s persepective. The user should be able to click on a URL at the issuer’s web site (same device flow), or scan in the QR code (cross device flow) and get the VC into their wallet.

This has already been implemented and works just fine, except that the client_id is not being presented to the token endpoint. So this is what we want to fix and the PR proposes a simple way of fixing this.

[Torsten Lodderstedt]

To me this means your issuer does not want to know anything about the wallet that is requesting the credential. That is surprising since your issuer gives a credential to an unknown party that will be responsible for the security of the credential going forward. And if a user asks the issuer für information were the credential went, the issuer can only answer “to you”.

If that is ok with you, you can define your own fixed client id that all wallets can use to interact with your issuer or you just accept any value for the client_id. That is even simpler than your proposal as it does not require an extension to the protocol with no benefits for others.

There are other schemes and deployments that want/need to know what wallet the issuer is interacting with, for example to make sure, they comply with certain regulatory obligations, follow the same policies or have a contractual relationship. In such a setup, the wallet will have a client id issued in advance with one of the mechanisms listed above.

[David W Chadwick]

To me this means your issuer does not want to know anything about the wallet that is requesting the credential.

Correct. There are many instances when the issuer does not care which wallet the user is using (in the same way that a web site might not care which browser you are using - and the web site might be showing you your bank details and allowing you to move money). VCs are very similar to PKCs from a technology perspective. They are secured in exactly the same way. So they cannot be tampered with. The difference is that VCs contain more PII than PKCs. So it is the user’s responsibility to keep their own PII private. If the issuer gives the VC to the user, and the user consents to this, it is the responsibility of the user to do with it what it wants. Some users may publish their VCs on LinkedIn. (They already do this with Open Badges). All users choose which wallet they want to use in the same way that they choose which browser they want to use. It really is no business of the issuer which wallet any user prefers to use.

So the bottom line is that your model, whilst being valid for some use cases like high valued VCs, is not the only valid model for VC issuing. The model we are using in JFF is perfectly valid for a qualification-like certificate.

[Torsten Lodderstedt]

If the issuer gives the VC to the user, and the user consents to this, it is the responsibility of the user to do with it what it wants.

Can you please explain how the user (on its own) ensures her credentials cannot be stolen and are safely managed by her wallet of choice? To me the philosophy you outline leaves the user on her own without any support. I’m in doubt this is gone work.

The model we are using in JFF is perfectly valid for a qualification-like certificate.

Where is that model used in production? I’m asking since I would like to learn what verifiers accept credentials issued that way.

‌

[David W Chadwick]

Where is that model used in production?

Today the OpenBadges model is that users publish their badges on LinkedIn so that anyone can validate them. I understand that there are millions of these in use today.

Can you please explain how the user (on its own) ensures her credentials cannot be stolen and are safely managed by her wallet of choice?

Can you explain how the user (on its own) ensures that her passwords cannot be stolen and are safely managed by the password manager of her choice today?

[David W Chadwick]

@Torsten Lodderstedt If that is ok with you, you can define your own fixed client id that all wallets can use to interact with your issuer

Thinking some more about your proposal, doesn’t this mean that all wallets from all users will be using the same client_id, so that when the user goes to the credential issuing end point and presents its client_id (which is in the proof token) that any user would be able to pick up any other user’s credentials?

[Torsten Lodderstedt]

I had a chat with Brian after last week’s call about how RFC 7523 customises the OAuth client identification/authentication behaviour for the JWT bearer token grant type to not require the client id.

I also talked to Daniel about the security implications of such a change. We both came to the conclusion that security wise a client id is not needed (in contrast to authz code) as pre authz code does not utilise a pre-configured redirect URI whitelist (as the authz code grant type does).

I suggest to change the text of the spec to allow to omit the client id for the pre-authz code flow and have filed the respective PR #351.

Please have a look and approve.

[Kristina Yasuda]

PR merged