search

endimion / ewc-wallet-conformance-backend

3 stars 1 forks source link

Implementation review #4

Open albertescotealvarez opened 6 months ago

albertescotealvarez commented 6 months ago

Hi Nikos!

As commented before I attach some things that I have found that may need some clarification or modification:

  1. How is authentication done in Authorization Code Flow? Is it done via id_token or vp_token authentication? Perhaps a "direct_post" endpoint is needed to receive authentication tokens.
  2. Right now credentials are issued using sd-jwt. We also need normal jwt.
  3. The endpoint token is defined as "token_endpoint" but the standard is simply "token".

Regards, Albert.

georgepadayatti commented 6 months ago

Hi Nikos!

As commented before I attach some things that I have found that may need some clarification or modification:

  1. How is authentication done in Authorization Code Flow? Is it done via id_token or vp_token authentication? Perhaps a "direct_post" endpoint is needed to receive authentication tokens.
  2. Right now credentials are issued using sd-jwt. We also need normal jwt.
  3. The endpoint token is defined as "token_endpoint" but the standard is simply "token".

Regards, Albert.

Agree to Points 1 and 2. But if implemented should be treated as optional flows.

Point 3:

As defined in the OpenID Connect Discovery specification, the field is named as token_endpoint. For reference: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata

endimion commented 6 months ago

Hi guys, I agree with @georgepadayatti . My plan is to add the functionality @albertescotealvarez suggests and then add new test cases on the ITB... We should discuss this however, over slack or on the RFC-repo and decide what we consider an "EWC" compliant implementation.

My only concern is that for piloting to be smooth and interoperable, all wallets that are "EWC" conformant need to implement all flows (or at lease what we deem as mandatory). This way, assuming that a relying party implements these same flows/specs the end users will be able to use whatever wallet app they want.

This has to do with Point 3 mainly. So, for example, i f a relying party is issueing/verifying sd-jwts then all wallets needs to support that... let's discuss more...

albertescotealvarez commented 6 months ago

Hi! Regarding @georgepadayatti's comment, it is true that the OpenID Provider Metadata object contains a field called "token_endpoint" which defines where the token endpoint can be found. However, the default value of the Token Endpoint is usually simply "/token", just as the Authorization Endpoint is usually defined as "/authorize" instead of "/authorize_endpoint". Thus, I agree that this is not an issue, but I think naming the endpoint as simply "/token" would avoid some possible errors to wallets that assume the Token Endpoint is under the path: CredentialIssuerURL+"/token".

On the other hand, regarding the format of the issued credentials, if the RFC specifies that the supported formats are "jwt_vc" and "sd_jwt_vc" I think the best way to deal with it is to use the "format" field in the OIDC4CI requests. That is, in the Credential Issuer Metadata object there is a field called "format" for each supported credential so that the wallet can check what format the credential it is looking for is in (https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-12.html#name-credential-issuer-metadata-p). Once the wallet has checked the format of the credential it is looking for, it can specify the format in the Authorize request even with the Authorization Details object or with the "scope" field. This will ensure the interoperability of the system between different wallets, as it is a working method included in the OIDC4CI standard.