[New Client Metadata Paramenter] presentation_definitions_supported

peppelinux commented 3 months ago

Problem and Requirement

There are cases where a trust framework or federative model introduces the requirement to approve during onboarding, and consequently to include in the client metadata the data that the client is authorized to request from users, such as credentials and individual attributes associated with them.

Solution Proposed

New Parameter Name

A new parameter can be defined to be included in the metadata, which refers to presentation_definition but has a different name and purpose.

presentation_definitions_supported is the proposed name for this parameter.

Approach To The Problem

During the RP registration within a federation/eID network, the presentation_definitions_supported in the metadata contains all the supported presentation definitions on which the presentation_definition used in the presentation request can be filtered, based on the trust framework used and compliance evaluation mechanisms.

Technically, the presentation_definition obtained in the presentation request must contain all or some of the IDs found in presentation_definitions_supported published in the metadata, such that the corresponding IDs lead to the use of the definitions contained in the metadata.

The IDs are intended as the top level parameters that each presentation definition object must contain, since it is required according to PE version 2.0.

The presentation_definitions_supported type is ARRAY[Object].

This enables the application of policies on requests and metadata without breaking compatibility with the current approach.

David-Chadwick commented 3 months ago

Technically, the presentation_definition obtained in the presentation request must contain all or some of the IDs found in presentation_definitions_supported published in the metadata,

And more importantly, it must NOT contain any IDs that are not in the presentation_definitions_supported

David-Chadwick commented 1 month ago

Q. What mechanism is used to bind the PD ID to the actual PD? In other words what is to stop a RP from putting a modified PD with a certified ID so that it asks for different credentials? In our implementation we stored the PDs in a policy database, and provided the URLs of certified PDs to wallets.

jogu commented 3 weeks ago

I'm not 100% clear how this mechanism works:

I think the suggestion is that the request contains only presentation definition ids, and the actual presentation definition to be used is looked up in the metadata.

Unfortunately that approach does not work with the browser API, as the wallet cannot fetch the metadata prior to determining if it has credentials that match the request. (This is a fundamental privacy property that comes from the browser API allowing multiple wallets but not wanting to leak any information to the wallet until the user has selected a credential - in particular the wallet matcher process that determines whether the wallet has a credential the user might be able to select or not is run in a sandbox that has no network access and hence the wallets cannot fetch a verifiers metadata at that stage.)

I would suggest that we should not adopt mechanisms that will be incompatible with the browser API unless we have really good reasons and an alternative that does work with the browser API.

Sakurann commented 3 weeks ago

Do I understand correctly that the verifier will still pass the presentation_definition and wallet will have to look up in the verifier's client_metadata if it contains an id for that presentation_definition in presentation_definitions_supported..? and the wallet establishes the trust in that client_metadata via verifier authentication?

jogu commented 3 weeks ago

I am struggling to see how a mechanism like this can be made to work with the browser API.

The information as to what credential is being requested clearly needs to be included in the original request for it to work with the browser API, in a way that it can be later verified (after a credential is selected and the Wallet can make network requests to do that verification).

The current suggested approach both here and in #182 also prevents using any kind of value based queries ('return a credential only if the first_name is "Jack" and the last name "Johnson"'').

The only sensible way I can see to do that is:

some kind of JWT signed by a third party is included in the request that contains a attested permitted query (which still prevents the use of value based queries).
there is some kind of separate way to express what credentials and fields a verifier is allowed to request, that is not expressed by providing lists of accepted presentation_definitions (or other json objects) that are expected to be compared for equality.

alenhorvat commented 3 weeks ago

At EBSI we employed a similar approach, however, we put the requirements/policies in the VC itself: RP/Verifier can request the VC if and only if it's capable of presenting attestations that give it right to request those (https://hub.ebsi.eu/vc-framework/trust-model/policies). - it's been implemented and tested. (here the proposed logic is reversed; I guess that the configuration in this case is signed and it belongs to a trust chain, else RP/Verifier can deny the information)

We also proposed 3 options

information is fetched from the .well-known (as described here)
information is passed in the authorisation request (as part of the client_metadata I think)
once a wallet receives a request, a VP flow is initiated by the wallet to essentially execute "mutual authentication" (used, depending on the security profile)

I guess if first two approaches are used, they can cover also the browser API use case.

@Sakurann , yes, presentation definition is also in the request, next to the (hopefully signed) metadata with the presentation_definitions_supported claim.

@jogu _The current suggested approach both here and in https://github.com/openid/OpenID4VP/issues/182 also prevents using any kind of value based queries ('return a credential only if the firstname is "Jack" and the last name "Johnson"'').

Actually you can define policies so that certain claims can be requested. E.g., only email and (delivery) address can be asked.

I hope this helps!

Nice to see similar ideas appearing in different contexts.

jogu commented 2 weeks ago

I think we need to go back to first agreeing exactly what we want to achieve before we talk about specific solutions - I've hence opened https://github.com/openid/OpenID4VP/issues/232 that aims to give a high level overview of the problem and a high level overview of possible solutions. I suggest we close this issue in favour of #232 and continue discussion there.

jogu commented 2 weeks ago

Thanks @alenhorvat ! I think what you are suggesting is a variant of my second proposal (essentially a 'permissions' language of some kind) on https://github.com/openid/OpenID4VP/issues/232 except it's basically using some of the properties of presentation exchange as the permissions language, which I think is slightly different from the original proposal above but I'm not 100% clear on the original proposal yet?

We also proposed 3 options

information is fetched from the .well-known (as described here)

information is passed in the authorisation request (as part of the client_metadata I think)

once a wallet receives a request, a VP flow is initiated by the wallet to essentially execute "mutual authentication" (used, depending on the security profile)

I guess if first two approaches are used, they can cover also the browser API use case.

I don't think "information is fetched from the .well-known (as described here)" works with the browser API as the information in the well-known is necessary to know whether the wallet has any credentials that match the request, but you can't fetch the well-known until the user has selected a credential?

peppelinux commented 1 week ago

I mentioned some of the reasons why having this information in the form of a third party attestable presentation definition within the RP metadata might have sense, here: https://github.com/openid/OpenID4VP/issues/232#issuecomment-2327366153

I believe that to resolve @jogu's concerns about the computational effort required against a comparison of two different json objects (already discussed here like a sort of programming challenge: https://bitbucket.org/openid/connect/pull-requests/459/openid-connect-federation-10-new-equals#comment-372647945) can be easily resolved by having presentation_definition_supported in the form of JSON object with key values matching the presentation definition id(s), where the ones used within the rp request would be used as lookup parameter to obtain the attested ones from the metadata.

the value of having this information in a third party attested metadata also meets the requirement of having a transparent and browsable federation, with participants explicitly claiming their needs and grants.

jogu commented 1 week ago

No one objected to closing this and continuing the discussion on https://github.com/openid/OpenID4VP/issues/232 so closing.

openid / OpenID4VP