what metadata goes into client_metadata parameter?
Issue #1814
resolved
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.
Comments (11)
-
-
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.
-
reporter
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
-
-
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_definitionanother 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 -
What about the proposal below?
Please note that:
- It’s a federation entity configuration, where the metadata type defines the entity type we’re dealing with: Verifier or wallet relying party.
- 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 bewallet_relying_partyor any other suggested in this WG. - 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?
presentation_definitionsis still unconventional and needs discussions. The requirement to have it in the metadata is the same of the previous point.- 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_definitions": [ { "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/" ] } }
-
instead of
presentation_definitionswhat about having in the wallet RP metadatapresentation_definition_supported?
-
reporter
default_acr_values
this may depends by each presented VC.
Does
acrapply to VCs? verifier will ask for a specific value and wallet will return? will verifier trust wallet’sacrvalue?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 usepresentation_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..
-
Does
acrapply 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 usepresentation_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 policyI’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
-
reporter
during the SIOP call we discussed there are three potential actions here:
- defining a
presentation_definitionmetadata 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)
- defining a
-
parameter availability motivation application_typeREQUIRED we have the proximity and remote flow. If the RP is remote this MUST set to web. if proximity .. proposal required here.client_idREQUIRED to uniquely identify the RP client_nameREQUIRED for UX on the consent page jwksCONDITONAL REQUIRED if jwks_uriorsigned_jwks_uriare not present.contactsRECOMMENDED for UX and the right to establish a direct contact to the assistance or to an organization technical or administartive representative request_urinote: 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 metadataCONDITIONALREQUIRED ifapplication_typeisweband 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
-
- changed status to resolved
Migrated to GitHub
- Log in to comment
- Assignee
- –
- Type
- Priority
- Status
- resolved
- Component
- Verifiable Presentation
- Milestone
- –
- Version
- –
- Votes
- 0
- Watchers
- 1
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?