[OpenID4VP] Relying Party presentation request, allowed scopes and policies

[Giuseppe De Marco]

For the reliability of a RP/Verifier there are an important discussion about how a Wallet Instance
is able to make selective disclosure considering just the user attributes allowed by a Trusted Third Party (TTP),
sharing a common Trust Framework.

Requirement

A RP MUST be allowed by a TTP to ask a specific set of user attributes

Current equipment

In https://datatracker.ietf.org/doc/html/rfc7591 we have the claim name scope as below

scope
      String containing a space-separated list of scope values (as
      described in Section 3.3 of OAuth 2.0 [RFC6749]) that the client
      can use when requesting access tokens.  The semantics of values in
      this list are service specific.  If omitted, an authorization
      server MAY register a client with a default set of scopes.

In https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-verifier-metadata-client-me, Section "9.1. Additional Verifier Metadata Parameters "
we read that OpenID4VP extends the claims defined in RFC7591 for the RP's metadata.

Assumptions

Since the reliability of a participant must be evaluated with a verifiable Key Attestation, following the mechanisms of one or several Trust establishment mechanisms,
at the same time the relaibility of a RP should be also attested by its metadata, satisfing the scope of interop schema attestation in relation to what the RP is able to do,
what it supports, and in general its behaviour.

While we have in these both Key Attestation and Interop Schema we need an additional property defined as Policy, that a coercitive
rule, issued by a TTP, regarding what a RP is granted to do.

The Policy may be applied to the metadata, as already happens in OpenID Connect Federation though its metadata policy (here: https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-verifier-metadata-client-me))
or I assume to a request, by someother customization based on verifiable attestations or Trust Marks (even this latter in OpenID Connect Federation).

Proposal

We should make it more clear that by applying a policy to a RP metadata,
we can filter out all the unallowed scopes that a RP may ask.

the policy overrides the metadata scopes and these will be filtered out in the rp request

Moreover, I'm aware that the scopes of a RP request can mix aggregated claims mapped in a well-known scope name (eg: profile) and also point to single claim names.
I'm wondering if it would be good to explicit better in the specs how a policy can be applied to this aspect, satisfying the requirement of how to apply a policy, following a specified Trust Model.

Is this issue more related to an higher profile related to how to apply a policy and obtaining a level of assurance regarding a RP or is this something that maybe introduced in OpenID4VP, following
what we already have, as example, in OpenID Connect Federation with the metadata policy applied to RP metadata?

[Giuseppe De Marco]

ISO 18013-5, Annex D.4.2.2 OIDC, page 97, exposes this example

{
"client_id": "ac55a761d4e74b35a9f2de06c3ea4f63",
"client_id_issued_at": 1569657361,
"client_secret": "OoZlNbaKSPQKWSLSc6AHTUFmpPOssio1",
"client_secret_expires_at": 0,
"grant_types": [
"authorization_code"
],
"client_name": "ac55a761d4e74b35a9f2de06c3ea4f63",
"client_uri": null,
"logo_uri": null,
"redirect_uris": [
"com.company.isomdlreader://login"
],
"Scope": "openid org.iso.18013.5.1:given_name org.iso.18013.5.1:family_name org.
iso.18013.5.1:birthdate"
}

‌

[Giuseppe De Marco]

During the Connect A/B call we agreed that this issue is ready to be closed, since it is not an issue but just a general consideration. We’ll wait for another week before closing it

[Giuseppe De Marco]

In https://openid.bitbucket.io/connect/openid-4-verifiable-presentations-1_0.html#section-5.3

we read that we can use the scope parameter in the request, however openid4vp doesn’t define a clear way to handle scopes for requesting specific VC or singular attributes contained in it

I suggest to reword the text below, since it is not clear what the alias means

Such a scope value MUST be an alias for a well-defined Presentation Definition that will be referred to in the presentation_submission response parameter.

I suggest to remove the text below

The specific scope values, and the mapping between a certain scope value and the respective Presentation Definition is out of scope of this specification.

Possible options include normative text in a separate specification defining scope values along with a description of their semantics or machine readable definitions in the Wallet's server metadata, mapping a scope value to an equivalent Presentation Definition JSON object.

giving a clear approach about how to use this parameter, herein a proposal

"scope": "eu.europa.ec.eudiw.pid.it.1 eu.europa.ec.eudiw.pid.1:given_name eu.europa.ec.eudiw.pid.1:email"

where an RP asks for an entire doctype (PID) and for specific user attributes available in a specific doctypes. This approach is also applicable to metadata policies (oidc federation) as raised in this issue.

This approach also simplifies the implementations, that are able to release SD attributes or entire VC without the requirement of presentation_definition. I also like to assume that different doctype may define different VC encoded in different format (sd-jwt, mdoc cbor)

[Giuseppe De Marco]

this issue is linked to https://bitbucket.org/openid/connect/issues/1841/openid4vp-presentation_definition_alias

[Kristina Yasuda]

we read that we can use the scope parameter in the request, however openid4vp doesn’t define a clear way to handle scopes for requesting specific VC or singular attributes contained in it

This is not accurate, since, as it was mentioned during the call today, there is this sentence in section 5.3:

Such a scope value MUST be an alias for a well-defined Presentation Definition that will be referred to in the presentation_submission response parameter.

which means each scope value must map to a clear way of requesting specific VC.

[Giuseppe De Marco]

Yes, I was looking about how this map should be done and how these alias should be done as well, and also how to represent this map in the client metadata.

So I’d like to move the discussion in this issue https://bitbucket.org/openid/connect/issues/1841/openid4vp-presentation_definition_alias and then close this one :-)

one less!