Wallet instance attestation equivalent to client metadata

[rohe]

There is no explicit client (/wallet) registration with OpenID Credential Issuers (OCI) hence the only thing an OCI knows about a wallet instance is what is in the wallet instance attestation (WIA).

In essence as the system is designed today the OCI does an automatic client registration of the wallet using as metadata the claims carried in the WIA.

The system would therefor benefit if we added claims like redirect_uri to the WIA. This would allow the OCI to do like all OIDC compliant OPs must do when it comes to verifying the redirect_uri included in the authorization request against the registered (in the WAI).

There could be others claims like default_acr_values that we'd also would like to include.

[fmarino-ipzs]

I agree with @rohe. I suggest having a metadata field to put all the relevant claims (redirect_uri, authorization_endpoint, etc.). Something like:

{
  "iss": "https://wallet-provider.example.org",
  "sub": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c",
  "attested_security_context": "https://wallet-provider.example.org/LoA/basic",
  "iat": 1687281195,
  "exp": 1687288395,
  "cnf":
  {
    "jwk":
    {
      "crv": "P-256",
      "kty": "EC",
      "x": "4HNptI-xr2pjyRJKGMnz4WmdnQD_uJSq4R95Nj98b44",
      "y": "LIZnSB39vFJhYgS3k7jXE4r3-CoGFQwZtPBIRqpNlrg",
      "kid": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c"
    }
  },
  "metadata":{
    "authorization_endpoint": "eudiw:",
    "redirect_uri": "eudiw:",
    "response_types_supported": [
      "vp_token"
    ],
    "vp_formats_supported": {
      "jwt_vp_json": {
        "alg_values_supported": ["ES256"]
      },
      "jwt_vc_json": {
        "alg_values_supported": ["ES256"]

      }
    },
    "request_object_signing_alg_values_supported": [
      "ES256"
    ],
    "presentation_definition_uri_supported": false,
 }
}

[balanza]

I see the value of client registration in a OpenID context. What's the benefit for our ecosystem?

[peppelinux]

@balanza following what we already have in the oppenid4vci flow and what is going to be consolidated in the presentation flow, we now have the requirement and the implementation of submitting the WIA before all (yes, even in the presentation and not just for italy ...)

this suggests a registration phase of the wallet to the issuer/RP, before this happens before anything else. It is a weak registration since the WIA is ephemeral, then it's a short lived registration.

then I would not say registration or say short-lived registration within a transaction, where the same wallet instance might use a different WIA with the same digital credentials and get registered within a transaction in the issuer/rp anyway.

however, here we're not discussing if it is a registration, if should, would or not, but if include the redirect_uri within the wallet instance metadata, that's definitively the WIA.

we have a way to use the WIA like the media for the metadata discovery about a wallet instance, now we're considering the claims that should be there

@rohe would you like to add something?

[balanza]

Let my just 5-why this. Why should we require ~client registration~ request_uri? What information does it bring?

[grausof]

I don't see any added value with adding these parameters. Furthermore, the Wallet Instance is an app so a redirect_uri or authorization_endpoint makes no sense. As already explained several times, deep links (eudiw://) are deprecated and perhaps we should switch to a universal link. But for now this is of no use.

[grausof]

Since this depends on: https://github.com/italia/eudi-wallet-it-docs/issues/186 I move the milestone to 0.7.0 since its dependency has the same milestone

[peppelinux]

As already explained several times, deep links (eudiw://) are deprecated and perhaps we should switch to a universal link. But for now this is of no use.

as mentioned before we cannot rely only on universal links, according to the future features and requirements based on W3C Credential API the universal links would be considered out in favor of the custom url scheme, thanks to the security and hijack resistance provided by user-agents.

in relation to the flow between the wallet instances and the wallet provider, there was a conversation in both Connect A/B and DCP WG on this and it seems that this point will be further discussed within the OpenID Federation Wallet Architecture draft, when/if it will adopted.

Instead of moving this issue to another milestone I would develop this topic within the openid wallet arch draft only and when further developements might happen take those in this specification as a general alignement with the openid standards/specs.

[peppelinux]

FYI: https://github.com/peppelinux/federation-wallet