[New Client Metadata Paramenter] presentation_definitions_supported

[peppelinux]

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]

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]

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]

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]

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]

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:

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

2. 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]

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 #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"'').

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]

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 #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]

Thanks @alenhorvat ! I think what you are suggesting is a variant of my second proposal (essentially a 'permissions' language of some kind) on #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?