[Openid-specs-ab] OpenID Federation Wallet Architectures Draft

Mon Aug 12 21:58:02 UTC 2024

Dear all,

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.

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.

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.

As discussed previously, the current draft introduces metadata parameters
that are under discussion within the DCP working group, which focuses on
OpenID4VC specifications.

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.

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:

1. To clarify and list parameters of interest for trust infrastructures and
policy application.
2. To enumerate open issues intersecting OpenID4VC and OpenID Federation,
and more broadly, OpenID4VC and trust infrastructures based on the
third-party trust model.

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:

OpenID4VP metadata, client_metadata
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.

OpenID4VP metadata parameter presentation_definition_supported
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.

OpenID4VCI metadata parameter jwks
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.

OpenID Federation Wallet Provider metadata
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.

OpenID Federation Wallet Provider metadata aal_values_supported
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.

OpenID4VP request_uris and response_uris_supported
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

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.
2. Allow for the randomization of endpoints by separating the constant and
attestable part from the randomizable part.

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.

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.

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:
https://github.com/openid/oid4vc-haip-sd-jwt-vc/issues?q=is%3Aissue+is%3Aopen+federation)
even having explicitly obtained the support of the community of the
implementers from more than one year at this part.

This inconsistency is also evident in SD-JWT-based Verifiable Credentials
(SD-JWT VC) (
https://drafts.oauth.net/oauth-sd-jwt-vc/draft-ietf-oauth-sd-jwt-vc.html#section-3.5),
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 (
https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/212#issuecomment-1948270093
).

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.

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.

Giuseppe

Il giorno lun 29 lug 2024 alle ore 23:30 Giuseppe De Marco <
demarcog83 at gmail.com> ha scritto:

> Dear OpenID Connect working group,
>
> The authors hereby contribute the attached OpenID Federation Wallet
> Architectures specification to the working group.  It defines OpenID
> Federation entity types for digital wallet architectures.
>
> The specification contents are attached in HTML format.
>
> Additionally, for the convenience of working group members, the
> specification source can be viewed at
> https://github.com/peppelinux/federation-wallet and the rendered HTML can
> be viewed at https://peppelinux.github.io/federation-wallet/main.html.
>
> Best wishes,
>
> Giuseppe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20240812/6a97361c/attachment.html>