add verifier_attestations parameter to authz req

[cre8]

Closes #396

[Sakurann]

Please add a change log :)

[cre8]

Please add a change log :)

done :)

[cre8]

I think this PR is in a decent state.

The only thing that worries me a bit is the question if we should add some form of ID on the root level of attachments to help a Wallet make a decision whether it needs to parse an attachment or not. I don't think it is a good idea to force a wallet to parse all attachments (in formats it understands) before being able to make a decision if it needs or understands them or not. Would feel cleaner to me if we added said id parameter to entries of attachments. Ecosystems would then need to define ids in a collision-resistant fashion.

I think the best approach would be to follow the JWT approach where the typ field defines the type of JWT and then there is a registry for the eco system or a global one where the values and how to deal with the attachment is defined. Since this field is on the root level of the attachment, the Wallet only needs to parse this value without anything else and can then decide how to continue.

[c2bo]

Not sure about the proof of possession part tbh

[c2bo]

I am not really happy with wallets having to parse everything first (to discover type) before understanding if it's relevant, but overall this variant seems to achieve the requirements

[c2bo]

Suggested change

	- **key-bound attestations**: The attestation's proof of possession is signed by the Relying Party with a key contained or related to the attestation . To bind the signature to the presentation request, the respective signature object should include the `nonce` and `client_id` request parameters. The attestation and the proof of possession have to be passed in the attachment.
	- **key-bound attestations**: The attestation's proof of possession is signed by the Verifier with a key contained or related to the attestation. To bind the signature to the presentation request, the respective object signed by the Verifier should include the `nonce` and `client_id` request parameters. The attestation and the proof of possession have to be passed in the attachment.

[cre8]

I am not really happy with wallets having to parse everything first (to discover type) before understanding if it's relevant, but overall this variant seems to achieve the requirements

Me neither, but since it's only parsing and not validating, it should be fine. If there occur attestations where it becomes more complex, we can add an optional attribute that can be used as an identifier. But at this point we were not able to find a good solution that pleased everyone.

[c2bo]

Suggested change

	- **claim-bound attestations**: The attestation is not signed by the Relying Party, but bound to it. The exact binding mechanism is defined by the type of the definition. For example for JWTs, the `sub` claim is including the distinguished name of the Certificate that was used to sign the request. The binding may also include the client_id parameter.
	- **claim-bound attestations**: The attestation is not signed by the Verifier, but bound to it. The exact binding mechanism is defined by the type of the definition. For example for JWTs, the `sub` claim is including the distinguished name of the Certificate that was used to sign the request. The binding may also include the client_id parameter.