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

Tue Jul 30 14:01:04 UTC 2024

Hi Joseph,
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.

Below are some clarifications by point. I will move these to GitHub issues
once this initial conversation concludes.

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.

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.

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.

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).

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).

I hope this clarifies the points. Let's continue this discussion and move
these points to GitHub issues for further tracking.
Best regards,
Giuseppe

Il giorno mar 30 lug 2024 alle ore 11:17 Joseph Heenan <joseph at authlete.com>
ha scritto:

> Hi all
>
> 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.
>
> 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.
>
> 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.
>
> 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.)
>
> Similarly I think there are much bigger questions to be asked about
> defining “jwks” for credential issuers (see
> https://github.com/openid/OpenID4VCI/issues/62 and or /.well-known/jwt-vc-issuer
> in
> https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-04.html#name-jwt-vc-issuer-metadata)
> 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:
> https://github.com/openid/OpenID4VP/issues/189
>
> Thanks
>
> Joseph
>
>
> On 29 Jul 2024, at 22:30, Giuseppe De Marco via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
> 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
> <main.html>_______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20240730/32d436e8/attachment-0001.html>