[3.x] Signing about webauthn

[DarkGhostHunter]

Currently you can add a new pipe to the ceremony pipeline to capture the challenge and re-save it with your own Bytestream. Challenge validation shouldn't be affected.

Since the 3.x allows to have a custom Challenge Repository, you may modify the challenge byte stream with a document hash for the given user.

If you care about determinism, you can encrypt the document hash with the app key, which always returns a different encrypted, but large, string.

I personally think this scenario is very niche and not mainstream, so I'll leave that as-is. I honestly think most users will want to use a Passkey on their devices without without limitations.

Securer apps will want to create their own ceremony workflows, which escapes this library purpose, even if it can be used as a basis for such implementation.

[DarkGhostHunter]

Buuuuuuuuuut... in 2.x this can be easily implemented in my end by just simply checking if the Challenge exist and not replace it if found.

[illambo]

Ok thanks for the suggestion.

[illambo]

In the end the solution I found most convenient (in v3.x) is to replace the Assertion\Creator\Pipes\CreateAssertionChallenge pipe with a custom one by binding it to the provider and extending Assertion\Creator\AssertionCreation class with custom data (in this way I avoid unnecessary push/pull on the challenge repository).

[DarkGhostHunter]

I see... I'll make a PR there to use an existing challenge, and add data to the challenge in a separate line. This way you don't need override pipes since these can change between minor or patch versions.

[illambo]

Ok I understand, thanks! If you don't find a comfortable or linear solution, don't worry.

[DarkGhostHunter]

Try the latest commit to 3.x

[illambo]

Perfect, it works and simplifies the objective of the topic, thanks again.