Terms Wallet, Client and RP

[Daniel Fett]

All three terms “Wallet”, “Client”, and “RP”/”Relying Party” are used in the document. I can see the need to use both Wallet and Client to emphasize the roles, but suggest to get rid of RP (or at least introduce it properly).

‌

[gffletch]

I think the issue with client is that it represents the “user-agent” which in the VP cases is often acting in the role of the “Authorization Server” which is not expected in normal OAuth texts. I agree we should have consistent language and we also need to ensure that readers unfamiliar with the whole decentralized-identity model can understand the “roles” the different components are performing in different protocol transactions.

[Vittorio Bertocci]

I was about to file an issue along the same lines - but there’s more. In addition to client(present in both uppercase and lowercase, implying a difference), RPand Wallet, Verifieris also used.

Being this an OAuth extension, I suggest we should try to use clientwhenever we talk about protocol considerations, and verifieronly when we are talking about specific behaviors/considerations tied to the fact that the client plays that particular role.

[Vittorio Bertocci]

also: @Daniel Fett from your text it seems you are implying wallet==client, but the way i understand it wallet==AS in OIDC4VP…

[Kristina Yasuda]

clientshould be all uppercase (lowercase is leftovers)

in 4VP, wallet == AS, for the RP/Client/Verifier, could we stick to verifier everywhere? I theoretically agree with trying “to use clientwhenever we talk about protocol considerations, and verifieronly when we are talking about specific behaviors/considerations tied to the fact that the client plays that particular role” but not sure how many readers can follow or make that distinction.

in VCI, wallet == Client, and suggest we stick to Wallet for consistency, and simplicity of reading. though, ideally, we would probably want to use both wallet and verifier depending on the context…

[Vittorio Bertocci]

To me the challenge is - if this is meant to be an extension to oauth, it should use oauth terminology. Or at least, that is what is customary with all existing extensions hence the likely expectation readers will have. I understand the challenge of the same entity playing different oauth roles at different times, but that looks inherent to the scenarios we are modeling here 🤷🏻‍♂️

[Daniel Fett]

Of course, wallet==AS in VP, I guess my mind wandered to the VCI world for a moment :-)

I’m not quite sure what the best solution here is, but sticking to the OAuth terminology can help readers to draw the parallels to RFC6749 more easily. In SD-JWT, we chose not to stick to the OAuth terminology as we are not defining a transport protocol and not re-using any steps from OAuth or OIDC. But VP and VCI are different.

[Kristina Yasuda]

I think a sentence like “In the context of this specification, Verifier acts as an OAuth 2.0 Client, and Wallet acts as an OAuth 2.0 Authorization Server“ for OID4VP and “In the context of this specification, Wallet acts as an OAuth 2.0 Client and Issuer acts as an OAuth 2.0 Authorization Server “ would be sufficient.

[Vittorio Bertocci]

the tricky part is that Verifier is not really a generic oauth client; it’s a client in the special case introduced by OpenID Connect, where the client is also the recipient of the requested token. In Oauth the client just asks for an access token for a resource and the case in which client and resource are the same entity is a special case… we can chat about it in the call in 30 mins if the agenda allows

[Kristina Yasuda]

suggested action. VCI spec currently says as below, try to fix the below part of Verifier definition to clarify relation to Client/RP:

Also called Relying Party (RP) or Client. During presentation of Credentials, Verifier acts as an OAuth 2.0 Client towards the Wallet acting as an OAuth 2.0 Authorization Server.

and VP spec currently says as below, try to fix the below part of Verifier definition to clarify relation to Client/RP:

Verifier

An entity that requests, checks and extracts the claims from Verifiable Presentations.

and throughout the spec use terms “verifier“.

[Nat Sakimura]

Kristina to take a crack at the concrete text.

[Kristina Yasuda]

PR #403. not sure term instance is the best one.

[Kristina Yasuda]

PR merged