How to retrieve client_name when using DID identifier scheme?

[cosminm-affnd]

The requirements in Authorization Request

Other metadata parameters MUST be ignored unless a profile of this specification explicitly defines them as usable in the client_metadata parameter.

In the case of using DIDs as client identifiers how should the wallet retrieve UX related information such as client_name, logo_uri and tos_uri?

[cosminm-affnd]

Chapter 10 requires the use of OAuth 2.0 Dynamic Client Registration Protocol , which unless I'm missing something is not compatible with DIDs because it assigns the client_id, and does not allow the client to register their did along side the other metadata.

Dynamic Client Registration would also require registration with every Wallet, which may lead to scalability issues.

[jogu]

Chapter 10 requires the use of OAuth 2.0 Dynamic Client Registration Protocol ,

Can you clarify which sentence says that? That is not the intention and in face the majority of systems I'm aware of don't use dynamic client registration. The use of client metadata values defined for use in DCR (e.g. authorization_signed_response_alg) does not mean that DCR is actually being used.

I don't know how to actually answer your question, that seems like it would be a question for someone that knows about DIDs and how you would obtain a trusted name for the owner of a particular DID. See the discussion here #17 (comment) for why the working group decided not to permit a self-asserted client_name.

[Sakurann]

I have heard a similar feedback before. Basically, the question it, "the wallet needs to display information about the RP (terms of services, logo, etc.) From where should the RP get that information?" it is usually not part of the RP authentication information. I think it is ok to put it in the client_metadata when the request is signed?

[jogu]

I think it is ok to put it in the client_metadata when the request is signed?

The working group was pretty negative on the client self-asserting its own name, logo, etc. It means any authorised player in the ecosystem can get the wallet to tell the user "You are releasing information to the US government" or whatever - see #17 (comment)

[cosminm-affnd]

@jogu I think I misunderstood

To convey Verifier metadata, Client metadata defined in Section 2 of [RFC7591] is used.

I read it as the only way to provide data about the Verifier to the Wallet.

The way we're solving this is by using JWT-Secured Authorization Request (JAR) always, which I think is @Sakurann's suggestion also. Since the whole request is signed, we can trust the integrity of the data inside. This still leaves the question wether the wallet should trust the request itself, but that seems outside the scope of Oid4VP.

An alternative that's more or less on the same line would be to support the removed client_metadata_uri and require the output of that uri to be signed.

Showing logo and name is the first interaction that most wallets will want to show, a unified mechanism across all client identifier schemes should both make it easier to support more in the future and increase compatibility.

[jogu]

The way we're solving this is by using JWT-Secured Authorization Request (JAR) always, which I think is @Sakurann's suggestion also. Since the whole request is signed, we can trust the integrity of the data inside. This still leaves the question whether the wallet should trust the request itself, but that seems outside the scope of Oid4VP.

There are two separate but related questions here. Firstly, does the wallet trust the request enough, and secondly what reliable information can the wallet display to the user about who the request is from so that the user is giving informed consent.

The suggest you have seems to be that the client self-asserts it's name, logo, etc. Suggesting that the request is signed (adding non-repudiation / tamper detection essentially) does not change the fact that the name & logo are self-asserted.

Maybe if you can explain how trust could be established that might make the answer clearer?

[David-Chadwick]

@jogu "Maybe if you can explain how trust could be established that might make the answer clearer"
I have answered this question a couple of times in other issues. Here it is again. Basically the wallet asks the trust infrastructure "can this self asserted name be trusted" and the trust infrastructure answers yes or no. If no, the transaction can be stopped immediately (or the user can decide to proceed with an untrustworthy RP).
If the answer is yes, there are only two alternatives. The RP is making a true statement or a false statement about its name.
In our implementation we did not believe or trust any statement that the RP made, therefore our trust infrastructure returned to the wallet all the information it needed about the trustworthy RP, and the wallet used this information when replying to the RP, and not the information provided by the RP (unless of course the RP had made true statements and the information was identical).

[jogu]

Thanks David.

So in your implementation any client_name etc passed in the request basically wasn't used and it would have worked without that information included in the request?

[David-Chadwick]

Not quite. The client name was the only thing used and passed to the trust infrastructure.

[David-Chadwick]

The rationale being "if you tell us your correct name, everything will be fine. If you give a false name, nothing will work for you"

[David-Chadwick]

Unless of course the user wanted to go ahead and talk to an untrustworthy site, because "the user knows best". This is the situation today with web browsers and TLS. The browser says 'site not trusted' but the user can usually bypass the controls if she is persistent and access the site anyway. So we used the same procedure in our wallet app.

[jogu]

Thanks David! That sounds unusual to be honest, it's quite different from the model in OID4VP where the client_id field is treated as the primary client identifier and I'm not sure how it could be codified into generically applicable spec language.

[David-Chadwick]

@jogu. Sorry, slight correction, since it's been 2 years since I stopped working on this implementation. We did use the client_id (sent in the OID4VP request) and required it to be the URL of the RP, and this was stored in its ETSI trust list entry of the RP.