[Openid-specs-digital-credentials-protocols] [notes] DCP WG + SIOP call

Wed Feb 19 18:08:11 UTC 2025

Hi All,
It was mentioned at the end of yesterday's call, but tomorrow's DCP WG call
(Th, Feb 20th), none of the co-chairs are available to chair, so we have
asked Christian to chair. He has graciously agree for which we are super
thankful. We have coordinated the agenda with Christian, which will be sent
out soon (the goal would be to conclude the discussion on issue 395 and PR
308 that we have started on Tue).
Best,
Kristina

On Wed, Feb 19, 2025 at 4:38 PM Christian Bormann via
Openid-specs-digital-credentials-protocols <
openid-specs-digital-credentials-protocols at lists.openid.net> wrote:

> Hi all,
>
>
>
> Below are the notes for this yesterday’s APAC DCP WG call.
>
>
>
> Best Regards,
>
> Christian
>
>
>
> ----
>
>
>
> Participants:
>
>
>
> Andres Olave
>
> Bjorn Hjelm
>
> Brian Campbell
>
> Christian Bormann
>
> Daniel Fett
>
> David Zeuthen
>
> Dima Postnikov
>
> Elizabeth Garber
>
> Gail Hodges
>
> Gareth Oliver
>
> George Fletcher
>
> Hicham Lozi
>
> Kristina Yasuda
>
> Lukasz Jaromin
>
> Martijn
>
> Michael Jones
>
> Oliver Terbu
>
> Rajvardhan Deshmukh
>
> Ryan Galluzzo
>
> Steve Venema
>
> Tim Cappalli
>
> Tobias Looker
>
> Torsten Lodderstedt
>
>
>
> ----
>
>
>
> Events/External orgs:
>
> - Contract with Stuttgart University for Security Analysis is in place
>
> - Remote Interop Prep
>
> - OID4VP Tests were released
>
> - EC agreed to have a meeting on conformance testing
>
> - EC inquiry as basis for official recognition of OpenID4VP and OpenID4VCI
>
> - Hybrid meeting before OSW
>
> - CSC
>
>
>
> ----
>
>
>
> https://github.com/openid/OpenID4VP/issues/395 - Clarify that signed
> requests for DC API should be rejected if the signature can't be verfied:
>
>
>
> Torsten explains the discussion that started with clarifying that the
> wallet should abandon a request if it cannot verify a request signature and
> moved on to discussion on downgrading. Torsten states his opinion that a RP
> does not randomly sign a request, but should know if the Request should be
> signed or unsigned in advance. He asks for opinions from the working group.
> Christian states that he thinks we need one way for a flow to allow both
> unsigned and signed options and the main question is whether that is
> explicitly signaled by the RP or a downgrade function (and decision)
> purely by the wallet.
>
> Martijn responds that he thinks signed requests are a layer on top and RP
> Authentication can provide a lot of different information. What an
> authentication means can be different case by case and Web PKI is something
> that is already used and should be perceived as a layer below. Martijn
> continues that the RP has no way to check if the wallet checked the
> signature correctly, so it is end up to the wallet anyway - it should not
> be up to a policy of the RP. Torsten responds that it was not about a RP
> policy, but about a choice of the RP how it is authenticated. Martijn
> states that there might be a small privacy issue if the RP can learn what
> trust issues the wallet supports. Torsten asks how a RP would deal with a
> signed (x.509 based) request and the wallet cannot verify the
> signature.Martijn and David respond that it is out of scope of the
> specification. David further explains that it should be out of scope of
> openid4vp, but probably in scope of a profile like HAIP. David continues
> that there might be ecosystems that require authentication with a specific
> trust framework, but others might not and would be fine accepting an
> unsigned request instead. David further explains that it should be in scope
> of the policy of the wallet - if a Wallet receives a signed request, but
> doesn't know the root CA, then it would respond normally.
>
> Steve comments that in the case of ecosystems of EUDI, there would be
> wallets that are not allowed to respond if they do not recognize the RP
> authentication and asks what would that mean to continue the flow in that
> context? Hicham states that the web-pki is a core part of the system and if
> it gets broken other parts of the protocol like origin breaks as well [
> missed some part here]. The RP cannot know everything about the wallet,
> which means that some parts of the requests are sent arbitrarily to the
> wallet. Depending on regulation and ecosystem, the wallet might behave
> differently - it might stop the flow, or it might continue. Kristina
> states that she is not convinced that it is a privacy issue that the RP
> learns which trust frameworks the wallet trusts. From a user perspective,
> the question would be what the expectation is – as a user, it would be the
> expectation that the wallet makes sure that the RP is trusted. Tobias
> responds that there are going to be ecosystems with different policies,
> like RP and wallet mandating the check of a trust framework. He agrees that
> a signed request is an additional layer that loses some value if the
> web-pki would be broken - it provides upfront authentication, but at the
> end it still requires web-pki to hold.
>
> Torsten responds that the WG seems to agree that it is up to the wallet
> policy, but we need to be clear on the client_id and make sure it is dealt
> with and used properly. Gareth explains that there have been cases where
> the requirement was to explicitly present the credentials from the wallet
> even if the RP Auth expired. Gareth explains that it doesn't make sense to
> him to have the RP opinionated. Torsten asks if the usnigned option
> protected by web-pki should be explicit by the RP, or it should only be the
> choice of the wallet to downgrade. Lukasz adds that it should be a policy
> that is attached to the credential. If authentication of the RP fails, the
> wallet should reply with an error.
>
> Christian states that we need to be careful how we deal with client_id as
> it is integral to the security of the protocol. Martijn responds that RP
> authentication can be used to provide information about the RP and he
> doesn't agree with the different IDs and it shouldn't be taken as a
> guarantee - that information might be used differently in different
> systems. Tobias states that the ID should be seen as the same entity
> identifying itself with different options - a human might do the same and
> use different ways to identify themselves in different ecosystems. He
> states that he dislikes the distinction of different client ids for the
> same entity that just uses different trust ecosystems. Torsten responds
> that there are two different types of identity - the logical identity (the
> company, name, etc.) and an identity that is bound to a trust ecosystem.
> One entity will have different client identifiers due to the different
> trust ecosystems. Torsten implores that the WG should be careful with
> what we do with the client identifiers (like having 2 different client
> identifiers in a response) and Lukasz agrees.
>
>
>
>
>
>
>
>
>
> *From: *Openid-specs-digital-credentials-protocols <
> openid-specs-digital-credentials-protocols-bounces at lists.openid.net> on
> behalf of torsten--- via Openid-specs-digital-credentials-protocols <
> openid-specs-digital-credentials-protocols at lists.openid.net>
> *Date: *Monday, 17. February 2025 at 18:05
> *To: *Digital Credentials Protocols List <
> openid-specs-digital-credentials-protocols at lists.openid.net>
> *Cc: *torsten at lodderstedt.net <torsten at lodderstedt.net>
> *Subject: *[Openid-specs-digital-credentials-protocols] [agenda] DCP WG +
> SIOP call
>
> Hi all,
>
> below is the suggested agenda for tomorrow's DCP WG + SIOP call at 9pm CET
>
>    1. OIDF Antitrust Policy at www.openid.net/antitrust applies
>    2. IPR reminder/ Note-taking
>    3. Introductions/re-introductions
>    4. Agenda bashing/adoption
>    5. Events/External orgs
>
>
>    1. Hybrid meeting before OSW
>
>
>    6. Issues and Pull Requests
>
> I would suggest to focus on the following issue and pull request as they
> are all related to RP authentication (with or without signatures):
>
> Wallet behavior if request signature validation fails
> https://github.com/openid/OpenID4VP/issues/395
>
> How to request credentials using RP credentials (requiring a signed
> request) and (in the same request) request credentials based on the web
> origin.
> https://github.com/openid/OpenID4VP/pull/308#issuecomment-2611251967
>
> How to determine the client identifier used to calculate the session
> transcript
> https://github.com/openid/OpenID4VP/pull/308
>
>
>
> best regards,
>
> Torsten.
> --
> Openid-specs-digital-credentials-protocols mailing list
> Openid-specs-digital-credentials-protocols at lists.openid.net
>
> https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250219/5d8a87c9/attachment-0001.htm>