<div dir="ltr"><div><br>Hi Joseph,<br>Thank you for your diligent reading. You've highlighted several weak points that need further development within the working group, which I was aware of. It feels like the work has just begun.<br><br>Below are some clarifications by point. I will move these to GitHub issues once this initial conversation concludes.<br><br>1. Connect or DCP WG: Federation is transversal, as trust evaluation mechanisms are, or at least should be, application protocol neutral. I would leave this decision to board members and other key personalities involved in the WG's scopes.<br><div><br></div><div>2. openid_wallet_relying_party vs. openid_wallet_client: Good point. I don't have a strong opinion on this. The only evidence driving my mind is that a wallet instance is a client during credential issuance, while during presentation, the client is the relying party. In the field of digital identities, I have always appreciated the distinction between client and relying party. At the same time, the new term "verifier" comes into play. At this stage, I would suggest that openid_wallet_client may sound ambiguous, while openid_wallet_verifier or openid_wallet_relying_party sounds more precise about the entity type. According to OpenID4VP, it seems that openid_wallet_verifier is more appropriate.</div><br>3. openid_wallet_provider: Considering the presence of the token endpoint, it seems more like an Authorization Server (AS). There are still open conversations about whether to configure the wallet provider as an AS or as an entity of its own. I found very interesting the opportunity to define this entity type within the openid specs.<br><div><br>4. aal_values_supported: This parameter was initially named "attested_security_context_supported" as a proposal for draft-ietf-oauth-attestation-based-client-auth, which mentions "attested_security_context". The scope of this optional parameter is to define the level of security the wallet provider supports and attests for the issuance of the wallet instance. I believe the responsibility for device security checks should lie with the wallet provider, not the credential issuers, who should rely on the trust established with the wallet providers (as WIA issuers).</div><div><br></div>5. Additional Metadata Parameters for Wallets/Verifiers: From my perspective, parameters like jwks should be included in OpenID4VCI, along with presentation_definitions_supported in OpenID4VP. We are on the same page here. The reason you find these in the draft under discussion is that we have implementation requirements looking forward to their satisfaction in the OpenID4VC specs, rather than this new one. Other elements like request_uris or response_uris_supported are more related to security enforcements brought by the verifiable evidences provided by the secure metadata exchange layer, provided by OpenID Federation (or any other mechanisms enabling the third party trust model).<br><br>I hope this clarifies the points. Let's continue this discussion and move these points to GitHub issues for further tracking.<br>Best regards,<br></div>Giuseppe<br><div><br><div><div><br><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mar 30 lug 2024 alle ore 11:17 Joseph Heenan <<a href="mailto:joseph@authlete.com">joseph@authlete.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hi all<div><br></div><div>Thanks for proposing this! I think we do need a spec that defines some federation terms for the issuer-holder-verifier model so if there were a call for adoption for work to define that I’d be broadly supportive.</div><div><br></div><div>I don’t think it’s immediately clear whether this should be a Connect or DCP working group item. In the current state (see below) I think it might be outside of the Connect WG’s scope, but this could change depending on the conclusion on the below points about metadata.</div><div><br></div><div>I would be interested to know why “openid_wallet_relying_party” was picked rather (say) “openid_wallet_client” (for consistency with “oauth_client”), and have similar questions about “wallet_provider” being used to refer to the “authorization server” side of a wallet.</div><div><br></div><div>I think there are questions to be asked about why additional metadata parameters for wallets/verifiers would be defined only for federation, for example “aal_values_supported” does not appear to be federation specific and hence, if it is generally applicable to many ecosystems, should be defined in OID4VCI. (If it is not generally applicable to many ecosystems it shouldn’t be in an OpenID spec at all.)</div><div><br></div><div>Similarly I think there are much bigger questions to be asked about defining “jwks” for credential issuers (see <a href="https://github.com/openid/OpenID4VCI/issues/62" target="_blank">https://github.com/openid/OpenID4VCI/issues/62</a> and or <span style="color:rgb(34,34,34);font-size:13.3px;background-color:rgb(249,249,249)">/.well-known/jwt-vc-issuer in </span><a href="https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-04.html#name-jwt-vc-issuer-metadata" target="_blank">https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-04.html#name-jwt-vc-issuer-metadata</a>) and I believe any initial version of this spec should not incorporate jwks so a robust discussion can be had about that before it is added to any working group spec. Similar questions arise around most of the items defined as verifier metadata too, e.g. presentation_definitions_supported is already proposed to be added to the VP spec: <a href="https://github.com/openid/OpenID4VP/issues/189" target="_blank">https://github.com/openid/OpenID4VP/issues/189</a></div><div><br></div><div>Thanks</div><div><br></div><div>Joseph</div><div><br><div><br><blockquote type="cite"><div>On 29 Jul 2024, at 22:30, Giuseppe De Marco via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:</div><br><div><div dir="auto"><p style="font-size:12.8px">Dear OpenID Connect working group,</p><p style="font-size:12.8px">The authors hereby contribute the attached OpenID Federation Wallet Architectures specification to the working group.  It defines <span style="font-size:10.5pt;font-family:"noto sans",sans-serif;color:rgb(34,34,34);background:white">OpenID Federation entity types for digital wallet architectures.</span></p><p style="font-size:12.8px"><span style="font-size:10.5pt;font-family:"noto sans",sans-serif;color:rgb(34,34,34);background:white">The specification contents are attached in HTML format.</span></p><p style="font-size:12.8px"><span style="font-size:10.5pt;font-family:"noto sans",sans-serif;color:rgb(34,34,34);background:white">Additionally, for the convenience of working group members, the specification source can be viewed at <a href="https://github.com/peppelinux/federation-wallet" style="text-decoration-line:none;color:rgb(66,133,244)" rel="noreferrer" target="_blank">https://github.com/peppelinux/federation-wallet</a></span><span style="font-size:10.5pt;font-family:"noto sans",sans-serif;background:white"> and the rendered HTML can be viewed at <a href="https://peppelinux.github.io/federation-wallet/main.html" style="text-decoration-line:none;color:rgb(66,133,244)" rel="noreferrer" target="_blank">https://peppelinux.github.io/federation-wallet/main.html</a>.</span></p><p><span style="font-size:10.5pt;font-family:"noto sans",sans-serif;background:white">Best wishes</span><span style="background:white;font-size:12.8px">, </span></p><p><span style="background:white;font-size:12.8px">Giuseppe</span></p></div>
<span id="m_-2160535079561524014cid:19100660c07ee51e6c02"><main.html></span>_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br><a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br></div></blockquote></div><br></div></div></blockquote></div>