I don't believe RPOrigins are not required to be fully qualified names in the library. Do you maybe mean the RPID? This has specific requirements which must be respected.

Hi @james-d-elliott,
I think the problem is here:

where the library formats the origin from the CollectedClientData as a fully qualified name. Which will not work for android, because android returns android:apk-key-hash:${androidHash} as origin and the format function then returns android:https://

Two possible solutions are:

1. remove the formatting
2. only format the origin when it does not start with android

Yeah you're right, thanks for putting the time in to find this. I will closely read relevant specs but it seems like this might be specifically the FIDO2 spec and is not part of the Webauthn spec at all. Which makes sense as it's not using Webauthn, it's a native API.

Webauthn itself requires this exact validation it seems, and the origin being formatted as a URL. As to how we solve it I'll have to closely look at the spec that governs it and it'll likely be similar to 2, but we'd use the full prefixes for those that exist (think there are two). I'm thinking it may also be wise to require this to be something that's explicitly enabled.

I would also be curious @nicksteele thinks if he has time to chime in (I would also like to remind him that there's a standing invitation to the org as a maintainer if he desires).

I've seen this before: passwordless-lib/fido2-net-lib#237

We ended up not formatting the origin if the origin had an unknown structure from UriHostNameType.

Thanks a lot Alex I really appreciate the insight. I'm.assuming there were no additional considerations?

Thx!

Apologies for chiming in 4 months later. The multiple auth origin scheme is android-specific currently. As far as I know there's no plans to have hashes or multiple origin IDs for other response types. @james-d-elliott now that I'm back from my startup sabbatical I'm happy to help as a maintainer.

Great news. I'll invite you to the org then.