Terms Wallet, Client and RP
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).
Comments (13)
-
-
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),RP
andWallet
,Verifier
is also used.Being this an OAuth extension, I suggest we should try to use
client
whenever we talk about protocol considerations, andverifier
only when we are talking about specific behaviors/considerations tied to the fact that the client plays that particular role. -
also: @Daniel Fett from your text it seems you are implying wallet==client, but the way i understand it wallet==AS in OIDC4VP…
-
client
should 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 useclient
whenever we talk about protocol considerations, andverifier
only 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…
-
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 🤷🏻♂️
-
reporter 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.
-
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.
-
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
-
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“.
-
- changed status to open
Kristina to take a crack at the concrete text.
-
-
assigned issue to
-
assigned issue to
-
PR #403. not sure term
instance
is the best one. -
- changed status to resolved
PR merged
- Log in to comment
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.