add more information on the binding to the origin in browser API

[Sakurann]

Given that binding to the origin is an important security feature, it is important to give more context on how the origin is used. This means we need to cover the following items in this PR:

• The origin is included in the cryptographic metadata used for response encryption and (credential format specific) device/key binding. It’s mandatory for the RP to verify whether this origin matches the origin it used to present the request, thereby preventing certain phishing attacks.
• Given that the origin is included in the cryptographic metadata in the response, including the expected_origins is in itself not necessary to prevent the phishing attack, but it does allow the wallet application to give an error earlier in the process.
• This means the following requirements apply:
  • If it’s a signed request, expected_origins must be included.
  • In the response encryption, origin must be included.
  • In the device/key binding, origin must be included.
  • If expected_origins is included, they must be verified by the wallet, if they don’t match the ‘actual’ origin, the transaction must be aborted.
  • The RP must verify the origin in the response and device/key binding mechanism, if it doesn’t match the ‘actual’ value, the transaction must be aborted.

Originally posted by @martijnharing in #155 (comment)

[Sakurann]

seems to be multiple issues:

• should expected_origins need to be included in the unsigned requests? current thinking is no, because JS injection is possible.
• should expected_origins need to be included in the response? in the unsigned request client_id == expected_origins, so already included in the response. For signed requests, aud is also probably sufficient -> need more text clarifying these.
• also how especially expected origins included in the response encryption