<div dir="ltr"><div>Dear all,<br><br></div>After having read some reactions I want to further clarify the scopes and the background behind the born of the OpenID Federation Wallet Architecture draft.<div><div><br>The primary goal of OpenID Federation is to define implementation methods for trust infrastructure, focusing on the secure exchange of metadata. The OpenID Federation Wallet Architecture draft highlights specific metadata parameters required for the reliability of participants, their attributes, and applicable policies within wallet ecosystems.<br><br>This draft details the use of OpenID Federation for digital identity ecosystems based on wallet technologies, identifying recognizable entity roles and the metadata they utilize.<br><br>As discussed previously, the current draft introduces metadata parameters that are under discussion within the DCP working group, which focuses on OpenID4VC specifications.<br><br>While OpenID Federation 1.0 has already extended entity metadata within an OpenID federation through OIDC and OAuth 2.0 experiences, fragmenting metadata parameter definitions across different drafts from various working groups would be inconvenient. It is evident that there is a need to converge and harmonize functional requirements recognizable across all working groups and drafts.<br><br>For this reason, I propose removing certain elements from the OpenID Federation Wallet Architecture draft that could ideally be defined within OpenID4VC. However, their current inclusion in the draft has been necessary for the following reasons:<br><br>1. To clarify and list parameters of interest for trust infrastructures and policy application.<br>2. To enumerate open issues intersecting OpenID4VC and OpenID Federation, and more broadly, OpenID4VC and trust infrastructures based on the third-party trust model.<br><br>The first point has led us to this draft, while the second requires further detailed consideration. Below, I list some interesting points and the reasons behind the choices defined in the draft:<br><br>OpenID4VP metadata, client_metadata</div><div>The term "Client" is too relative in wallet architectures, as it refers to the wallet during the issuance phase and the verifier during the presentation phase. This ambiguity suggests that the traditional OAuth2.0 definition of "client" does not adequately distinguish the roles typical of wallet architectures. Therefore, the draft introduces openid_wallet_relying_party metadata with the possibility of modification.<br><br>OpenID4VP metadata parameter presentation_definition_supported</div><div>Introduced to ensure presentation definitions within metadata are secured by a trusted third party, preventing over-asking by verifiers. A similar mechanism will be identified for the new query language being adopted.<br><br>OpenID4VCI metadata parameter jwks</div><div>Each entity within wallet ecosystems may need to sign requests, responses, and more stringently, credentials, assertions, attestations, etc. Currently, OpenID4VCI does not include public keys for signature verification within the metadata, which ideally should be available in other types of metadata (e.g., SD-JWT VC). This omission creates confusion among implementers and in particular a gap for implementers that needs to issue other credential data formats, not sd-jwt vc.<br><br>OpenID Federation Wallet Provider metadata<br>This should become an extension of the OAuth 2.0 Authorization Server, and the current draft should include the authorization endpoint or reference a new draft defining this specific Authorization Server in the form of a wallet provider.<br><br>OpenID Federation Wallet Provider metadata aal_values_supported</div><div>Initially attested_security_context_supported, it had a reference to an undefined attested_security_context in OAuth Attestation Based Client Authentication. A careful evaluation of the name and any dependencies on other trust frameworks, such as those defined by NIST, is advisable. More neutral and inclusive names and references should be used.<br><br>OpenID4VP request_uris and response_uris_supported</div><div>While I do not have a strong opinion on the names, there are two clear security and functional requirements: obtaining attestable endpoints from a trusted third party and allowing endpoint randomization. These are<br></div><div><br></div><div>1. Obtain attestable endpoints from a trusted third party, ensuring that no implementation or design flaws in the current specifications could allow an adversary to redirect the wallet instance to unsanitized endpoints.<br>2. Allow for the randomization of endpoints by separating the constant and attestable part from the randomizable part.</div><div><br>The point about metadata parameters defined in the OpenID Federation Wallet Architecture is that it does not make sense to remove them from the draft without securing their inclusion in the OpenID4VC specifications. Doing so would create a stalemate for those implementing OpenID4VC within trust infrastructures based on the third-party trust model.<br><br>Beyond metadata parameters, there are more architectural points, such as identifying wallet types. It is necessary to introduce wallet types controlled by legal persons, not necessarily installed on personal devices, and thus outside the control of natural persons. Additionally, other types of cloud-based wallets could converge on the concept of a federated entity, but for the sake of harmonization and simplification, the draft aims to normalize and treat them the same as any personal wallet through similar trust attestation mechanisms.<br><br>Lastly, it seems that all of us urge to all authors and members of the OpenID Foundation to focus on harmonizing and converging our efforts. An example of the fragmentation that currently leads us to reflect on the consequences of confusion and disorientation can be seen in the lack of clarity on why OpenID Federation is not implemented in OpenID4VC High Assurance Interoperability Profile with SD-JWT VC, despite numerous issues related to trust evaluation management and specifically the use of OpenID Federation (see: <a href="https://github.com/openid/oid4vc-haip-sd-jwt-vc/issues?q=is%3Aissue+is%3Aopen+federation">https://github.com/openid/oid4vc-haip-sd-jwt-vc/issues?q=is%3Aissue+is%3Aopen+federation</a>) even having explicitly obtained the support of the community of the implementers from more than one year at this part.<br><br>This inconsistency is also evident in SD-JWT-based Verifiable Credentials (SD-JWT VC) (<a href="https://drafts.oauth.net/oauth-sd-jwt-vc/draft-ietf-oauth-sd-jwt-vc.html#section-3.5">https://drafts.oauth.net/oauth-sd-jwt-vc/draft-ietf-oauth-sd-jwt-vc.html#section-3.5</a>), which introduces DIDs (to my great pleasure) but does not mention OpenID Federation in any way. It appears that there has been no opportunity to adequately develop this topic (<a href="https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/212#issuecomment-1948270093">https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/212#issuecomment-1948270093</a>).<br><br>This lengthy recap expresses my full support for reducing fragmentation for proper harmonization of specifications to best serve our implementers, with the understanding that simply removing parameters from the draft or delaying its adoption is insufficient, what is required is a holistic view of trust frameworks and wallet architectures. It is essential that OpenID specifications do not lead to mutual exclusion but rather to harmonization.<br><br>For this goal, my support is unconditional, unbounded by any external limits, constraints, or mandates from organizations or institutions. I hope that this conversation will yield the fruitful outcomes we all strive to achieve.<br><br></div><div>Giuseppe<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno lun 29 lug 2024 alle ore 23:30 Giuseppe De Marco <<a href="mailto:demarcog83@gmail.com">demarcog83@gmail.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 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>
</blockquote></div>