Add "Relay Attacks" to security considerations

[OR13]

covering cases where challenges are forwarded / related to holder binding / VPs, etc...

We should describe when relay is legitimate, and where it might cause problems.

relevant attacks on in person presentation, or man in the middle... etc.

[OR13]

Related thread from RATs WG at IETF:

• https://mailarchive.ietf.org/arch/msg/rats/K4Sqb3aub6uJh0So55NueWsqhM4/
• https://mailarchive.ietf.org/arch/msg/teep/duichdui0cGAF_ET3fphi9CSGJk/

[awoie]

IMO, we cannot say when relay is legitimate. We can only point out under which circumstances relay can happen and what verifiers can do to mitigate that risk. I suggest, after we merge PR #1054, we extend the security considerations section to add some language around relay.

[awoie]

This issue is blocked by the holder binding discussion. It really depends on whether such a feature is available. It makes a difference for the security consideration section whether a VC has some protection against impersonation or not.

[OR13]

Closing this issue, I think it is not addressable in the core data model, it applies to securing formats.

[TallTed]

Closing this issue, I think it is not addressable in the core data model, it applies to securing formats.

You opened this as a Security Consideration, which it remains, and which does not require addressing in the core data model — Security Considerations are about awareness and consideration regarding whatever deployment...

So I don't understand its closure, as opposed to adding a few sentences to the Security Considerations section.

[OR13]

@TallTed you are welcome to raise a new issue or file a PR that implements changes you want to see.