search

italia / eudi-wallet-it-docs

Italian EUDI Wallet Technical Specifications
Creative Commons Zero v1.0 Universal
54 stars 18 forks source link

OpenID4VP pending issues #34

Closed peppelinux closed 5 months ago

peppelinux commented 1 year ago

we have these implementation choices in our implementation profile:

  1. name of the metadata: wallet_relying_party

  2. submission of the wallet instance attestation to the request_uri endpoint using DPoP as proof of possession -> not mandatory, so it's not a breaking change. It fills the gap that openid4vp doesn't give clearance about the metadata discovery about a wallet instance (that must be secure and privacy preserving ...) -> see https://github.com/openid/OpenID4VP/pull/52

  3. presentation_definition -> https://bitbucket.org/openid/connect/pull-requests/586 -> still concerns in the IETF WG, we wait for updates

  4. we use redirect_uri in both metadata and request object and this latter MUST be signed

Sakurann commented 1 year ago

  1. what are you using wallet_verifier metadata for?

  2. for wallet attestation, have you looked at the oauth based client attestation draft?

  3. Am I correct to understand that a static presentation_definition metadata parameter is what you are looking for?

peppelinux commented 1 year ago

Ciao Kris

  1. We decided to use wallet_relying_party for the metadata identifier, since we can't use jwt-issuer as entity identifier because it's formless and too much abstract. In an ecosystem an entity may have more than a single role (defined in the ARF), that's why is important to distinguish them. wallet_relying_party allow us to not inflate the openid_relying_party metadata. Example: https://italia.github.io/eidas-it-wallet-docs/en/relying-party-solution.html#relying-party-entity-configuration

  2. We have started from it and then we have decided to work on this approach https://github.com/italia/eidas-it-wallet-docs/blob/versione-corrente/docs/en/wallet-instance-attestation.rst#dynamic-view-of-the-components and then come to ietf with comparisons and contributions. https://github.com/vcstuff/draft-looker-oauth-attestation-based-client-authentication is in our radar. @grausof please feel free to say yours. @Sakurann any authors like Tobias can open issues to explain why draft-looker-oauth-attestation-based-client-authentication would be better than the actual approach and give comparison and consideration. That would the best way to go for us

  3. yes, and also a conventional way for the presentation definition IDs, since they should be used in the scope so then they must not have spaces chars in the values. Otherwise we'll need another metadata parameter for mapping the aliases/scope to PEs while I think that we just need a way to normate the PE id values in OpenID4VP.

and ... 4. We are working on an approach to make the RP able to get the Wallet Instance before the issue of the request. We have in the specs DPoP on the request_uri endpoint but also rfc7521 is in our radar. This touches OpenID4VP Section 8 (Wallet Metadata Discovery)

peppelinux commented 1 year ago

I hope that this proposal helps to address the 2nd and the 3th points

https://bitbucket.org/openid/connect/issues/1814/what-metadata-goes-into-client_metadata#comment-65741984

aarmam commented 10 months ago

@peppelinux Could you please provide more details how you plan to resolve OpenID4VP/#39?

DeviceAuthentication.SessionTranscript.EReaderKeyBytes seems to be required field so can DeviceAuthentication.SessionTranscript.DeviceEngagementBytes be used without EReaderKeyBytes?

I was hoping to use DeviceNameSpacesBytes to include nonce from OpenID4VP authorization request but SessionTranscript is required element (at least in the current version of ISO/IEC 18013-5).

KristinaYasuda mentions that ISO 23220-4/18013-7 has defined a way how to put nonce in mdoc. Do you have access to these standards?

peppelinux commented 5 months ago

Partially resolved, pending tasks in new issues