what metadata goes into client_metadata parameter?

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1814

Original Reporter: KristinaYasuda

currently we just say that any client metadata can go into a client_metadata parameters, but I think parameters like redirect_uris, response_types, grant_types should be prohibited to be included.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

The parameters you listed don’t make sense as they are typically used by the AS to check whether the actual request parameters match. It might be worthwhile to go through the list of metadata parameters and whether there are more constraints we need to defined. For example, does it make sense to pass multiple kyes?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

I think if we specify the trust model that we are using for both issuing and presenting VCs then it will become much clearer which parameters are trustworthy and which are not - and the latter can therefore introduce vulnerabilities.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

I made the first pass to what I think should be allowed/prohibited/conditional:

For both OID4VP and SIOPv2

• Prohibited

  • redirect_uris
  • response_types
  • grant_types
  • request_uris
  • initiate_login_uri

• Allowed

  • application_type (not sure how valuable..)
  • contacts
  • client_name
  • logo_uri
  • client_uri
  • policy_uri
  • tos_uri
  • subject_type
  • token_endpoint_auth_method
  • token_endpoint_auth_signing_alg

• Conditional to trust_methods/client_id_formats

  • jwks_uri
  • jwks

• Not sure (think allowed)

  • sector_identifier_uri
  • default_acr_values
  • require_auth_time
  • default_max_age

Only SIOPv2

• prohibited

  • id_token_signed_response_alg
  • id_token_encrypted_response_alg
  • id_token_encrypted_response_enc
  • userinfo_signed_response_alg
  • userinfo_encrypted_response_alg
  • userinfo_encrypted_response_enc
  • request_object_signing_alg
  • request_object_encryption_alg
  • request_object_encryption_enc

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

default_acr_values
this may depends by each presented VC. Let’s suppose that we may have different credentials of the same type but with different LoA (eg: different european member state issues the same document with different LoA). Given LoA as requirement, it should be in the presentation_definition

another chapter should be open for the presentation_definition that to date we can submit only in the authorization request, while we really need it also in the metadata, allowing a RP to use the one it gives in its metadata, without explicitly specify this in the auzh request. WDYT?

Another capther would be for aliased presentation definition in scopes. The metadata would define the presentation_definition_scope_alias.
this would allow to define presentation defintion and scope aliases in the metadata, and then using the aliases in the scope parameter of the request

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

What about the proposal below?

Please note that:

1. It’s a federation entity configuration, where the metadata type defines the entity type we’re dealing with: Verifier or wallet relying party.
2. in my team there is a certain sensitivity not to define this entity as a relying party but rather to specialize it with the name of wallet verifier, this to not collide with metadata type openid_relying_party , an alternative could be wallet_relying_party or any other suggested in this WG.
3. redirect_uris and request_uris are required for the security of the solution, since all the resources listed there should be attested by a trusted third party. Why these are marked as **Prohibited** by Kristina?
4. presentation_definitions is still unconventional and needs discussions. The requirement to have it in the metadata is the same of the previous point.
5. PE with sd-jwt input descriptor needs to be discussed here: https://bitbucket.org/openid/connect/issues/1580/openid4vps-add-sd-jwt-example

{
    "alg": "RS256",
    "kid": "2HnoFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs",
    "typ": "entity-statement+jwt"
}
.
{
    "exp": 1649590602,
    "iat": 1649417862,
    "iss": "https://rp.example.it/",
    "sub": "https://rp.example.it/",
    "jwks": {
        "keys": [
            {
                "kty": "RSA",
                "n": "5s4qi …",
                "e": "AQAB",
                "kid": "2HnoFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs"
            }
        ]
    },
    "metadata": {
        "wallet_relying_party": {
            "application_type": "web",
            "client_id": "https://rp.example.it",
            "client_name": "Name of an example organization",
            "jwks": {
                "keys": [
                    {
                        "kty": "RSA",
                        "use": "sig",
                        "n": "1Ta-sE …",
                        "e": "AQAB",
                        "kid": "YhNFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs",
                        "x5c": [ ... ]
                    }
                ]
            },

            "contacts": [
                "ops@rp.example.it"
            ],

            "request_uris": [
                "https://rp.example.it/authz"
            ],
            "redirect_uris": [
                "https://rp.example.it/cb"
            ],

            "default_acr_values": [
                "https://www.spid.gov.it/SpidL2",
                "https://www.spid.gov.it/SpidL3"
            ],

            # not sure that's really required anymore here ...
            # "client_metadata": {
              "vp_formats": {
                 "jwt_vp_json": {
                    "alg": [
                       "EdDSA",
                       "ES256K"
                    ]
                }
              },
              "presentation_definition": [
                  {
                    "id": "SD-JWT-sample",
                    "name": "Person Identification Data",
                    "purpose": "User authentication",
                    "input_descriptors": [
                        {
                            "id": "sd-jwt",
                            "format": {
                                "jwt": {
                                    "alg": [
                                        "RS256",
                                        "ES256",
                                        "PS256"
                                    ]
                                },
                                "constraints": {
                                    "limit_disclosure": "required",
                                    "fields": [
                                        {
                                            "path": [
                                                "$.sd-jwt.type"
                                            ],
                                            "filter": {
                                                "type": "string",
                                                "const": "PersonIdentificationData"
                                            }
                                        },
                                        {
                                            "path": [
                                                "$.sd-jwt.cnf"
                                            ],
                                            "filter": {
                                                "type": "object",
                                            }
                                        },
                                        {
                                            "path": [
                                                "$.sd-jwt.family_name"
                                            ],
                                            "intent_to_retain": "true"
                                        },
                                        {
                                            "path": [
                                                "$.sd-jwt.given_name"
                                            ],
                                            "intent_to_retain": "true"
                                        },
                                        {
                                            "path": [
                                                "$.sd-jwt.unique_id"
                                            ],
                                            "intent_to_retain": "true"
                                        }
                                    ]
                                }
                            }
                        }
                    ]
                  },
                  {
                    "id": "mDL-sample-req",
                    "input_descriptors": [
                        {
                            "id": "mDL",
                            "format": {
                                "mso_mdoc": {
                                    "alg": [
                                        "EdDSA",
                                        "ES256"
                                    ]
                                },
                                "constraints": {
                                    "limit_disclosure": "required",
                                    "fields": [
                                        {
                                            "path": [
                                                "$.mdoc.doctype"
                                            ],
                                            "filter": {
                                                "type": "string",
                                                "const": "org.iso.18013.5.1.mDL"
                                            }
                                        },
                                        {
                                            "path": [
                                                "$.mdoc.namespace"
                                            ],
                                            "filter": {
                                                "type": "string",
                                                "const": "org.iso.18013.5.1"
                                            }
                                        },
                                        {
                                            "path": [
                                                "$.mdoc.family_name"
                                            ],
                                            "intent_to_retain": "false"
                                        },
                                        {
                                            "path": [
                                                "$.mdoc.portrait"
                                            ],
                                            "intent_to_retain": "false"
                                        },
                                        {
                                            "path": [
                                                "$.mdoc.driving_privileges"
                                            ],
                                            "intent_to_retain": "false"
                                        }
                                    ]
                                }
                            }
                        }
                    ]
                }
            ],
            "default_max_age": 1111,

            # SIOPv2 related
            "subject_type": "pairwise",
            "require_auth_time": true,
            "id_token_signed_response_alg": [
                "RS256",
                "ES256",
                "PS256"
            ],
            "id_token_encrypted_response_alg": [
                "RSA-OAEP",
                "RSA-OAEP-256"
            ],
            "id_token_encrypted_response_enc": [
                "A128CBC-HS256",
                "A192CBC-HS384",
                "A256CBC-HS512",
                "A128GCM",
                "A192GCM",
                "A256GCM"
            ],
        },
        "federation_entity": {
            "federation_resolve_endpoint": "https://rp.example.it/resolve/",
            "organization_name": "OpenID Wallet Verifier example",
            "homepage_uri": "https://rp.example.it/home",
            "policy_uri": "https://rp.example.it/policy",
            "logo_uri": "https://rp.example.it/static/logo.svg",
            "contacts": [
               "tech@example.it"
             ]
        }
    },
    "authority_hints": [
        "https://registry.eudi-wallet.example.it/"
    ]
  }
}

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

instead of presentation_definitions what about having in the wallet RP metadata presentation_definition_supported ?

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

default_acr_values

this may depends by each presented VC.

Does acr apply to VCs? verifier will ask for a specific value and wallet will return? will verifier trust wallet’s acr value?

another chapter should be open for the presentation_definition that to date we can submit only in the authorization request, while we really need it also in the metadata,

Right now, if you want to publish a static presentation_definition, you would use presentation_definition_uri.

Another capther would be for aliased presentation definition in scopes. The metadata would define the presentation_definition_scope_alias.

interesting.. might be worth considering..

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

Does acr apply to VCs?

good one, it should, since there are some legacy credentials with LoA substantial and not High

Right now, if you want to publish a static presentation_definition, you would use presentation_definition_uri.

good one but unfortunately this doesn’t fit the requirements that an accreditation body have in validating RP metadata.
I assume, as a requirement in a federative context, that the metadata should be signed by a Trusted Third PArty or at least a verifiable attestation is issued containing the relevant metadata properties and policy

I’m asking to have the presentation definition in the metadata and optionally in the request, since at this moment we just have these in the request and this doesn’t fit a federative approach

presentation_definition_scope_alias

regarding this one, there the will in my context to use scope anyway and have aliased presentation definitions as scope. In the discussion also Takahiko raised his concerns, I agree that’s an hot topic on the table that requires some effort. I’m on it, let’s try to discuss and find the way to go together

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

during the SIOP call we discussed there are three potential actions here:

• defining a presentation_definition metadata parameter
• what existing oauth metadata parameters are prohibited/allowed (original issue)
• (I think) how the verifier communicates that it’s metadata is attested (verifier_attestation client_id scheme)

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

parameter	availability	motivation
application_type	REQUIRED	we have the proximity and remote flow. If the RP is remote this MUST set to web. if proximity .. proposal required here.
client_id	REQUIRED	to uniquely identify the RP
client_name	REQUIRED	for UX on the consent page
jwks	CONDITONAL	REQUIRED if jwks_uri or signed_jwks_uri are not present.
contacts	RECOMMENDED	for UX and the right to establish a direct contact to the assistance or to an organization technical or administartive representative
request_uri note: there are some cases where for security reason this endpoint could be extended with session unique identifiers needed in the cross device flows. for this reason we should mention that the FQDN of the request_uri should be the equal to RP’s but we cannot mandate a static definition of it in the metadata	CONDITIONAL	REQUIRED if application_type is web and when the RP supports that. If the RP request a uri that is not defined in this list or this parameter is not present, the wallet instance should reject the request. The presence of this parameter allows an accreditation body to apply policies on the allowed request_uris.
default_max_age	OPTIONAL	Default Maximum Authentication Age. Specifies that the End-User MUST be actively authenticated if the End-User was authenticated longer ago than the specified number of seconds. The max_age request parameter overrides this default value. If omitted, no default Maximum Authentication Age is specified. See Section 2 of OpenID Connect Dynamic Client Registration 1.0
subject_type	OPTIONAL	SIOPv2 related
require_auth_time	OPTIONAL	SIOPv2 related
id_token_signed_response_alg	RECOMMENDED	SIOPv2 related
id_token_encrypted_response_alg	RECOMMENDED	SIOPv2 related
id_token_encrypted_response_enc	RECOMMENDED	SIOPv2 related
authorization_signed_response_alg	OPTIONAL	JARM related
authorization_encrypted_response_alg	OPTIONAL	JARM related
authorization_encrypted_response_enc	OPTIONAL	JARM related
attested_security_context_supported_values	OPTIONAL	non-IANA. In harmonization with attested_security_context represented here https://vcstuff.github.io/draft-looker-oauth-attestation-based-client-auth/draft-looker-oauth-attestation-based-client-auth.html#appendix-A.1; and defined in the Italian EUDI Wallet Solution, for both wallet provider and wallet relying party here: https://github.com/italia/eudi-wallet-it-docs/blob/versione-corrente/docs/en/wallet-solution.rst#payload-wallet_provider; and for wallet instance attestation here: https://github.com/italia/eudi-wallet-it-docs/blob/versione-corrente/docs/en/wallet-instance-attestation.rst#payload-1
redirect_uris	CONDITIONAL	the same motivation given for request_uris
default_acr_values	OPTIONAL	There are some cases where the RP made known the supported LoA. If not respected by the presenter, the presentation should be rejected.
vp_formats	REQUIRED	this makes known to the wallet instance if it has the capabilities to present a digital credential to the RP
presentation_definition	REQUIRED	this makes known which are the presentation definitions that the RP may request. Having it in the metadata this allows an accreditation body to configure policy on the metadata, or it issues verifiable_attestations with the entire list or a subset of the presentation definition supported. There are some cases where a wallet solution discover in the entire network (trusted Lists, Federation …) which are the RP and then their metadata to survey the technical capabilities required for the best interop. There are some cases where the request contains just the scope parameter (or an alternative presentation_definitions_ids parameter) containing the presentation definition ids, made available in the rp’s metadata. IF this is true, then we should define in OpenID4VP that the presentation_definition id MUST NOT contain space characters in theis ID values.
default_max_age	OPTIONAL	Default Maximum Authentication Age. Specifies that the End-User MUST be actively authenticated if the End-User was authenticated longer ago than the specified number of seconds. The max_age request parameter overrides this default value. If omitted, no default Maximum Authentication Age is specified. See Section 2 of OpenID Connect Dynamic Client Registration 1.0

‌

[paulbastian]

@Sakurann @peppelinux @tlodderstedt
I would like to pick up this topic again.

If I compare this with what we have in OpenID4VCI, I see a disparity.

Developers at Bundesdruckerei stumbled over this and were confused as there is little guidance how DCR client metadata fits into OpenID4VP. I would like to see more normative parameters inside the OpenID4VP spec.