Firstyear

That's okay @RatCornu - we're still working on it in the background ourselves, so it's not forgotten.

Still not forgotten :) We just have other priorities right now is all, so we haven't been able to look at this right now. There have been some small bits...

What is missing is not the API to submit the fields - be that the legacy API you reference or with SCIM PUT. The issue is *schema and access management*....

> I think it would be already a great improvement if more of the already specified user attributes would be available, especially birthday, phone number, address and in my case...

I haven't used hydra or kratos, so I can't fully compare them.

First, you should not be packaging crates for a distro. It goes against how Rust works as a language. I will update compact_jwt however.

PAKEs would indeed be better. It doesn't take long looking at past technologies like kerberos to see how simplying using a KDF is open to attacks.

Yeah, this sounds like a flaw in the program you are calling. Currently the alias paths are symlinks, not bind mounts. So some applications struggle to deal with this.

Because we haven't tagged them in the past is why you can't find them. @micolous Do you think we should do this in the future (and retrospectively add them?)

https://www.w3.org/TR/webauthn-3/#dictionary-makecredentialoptions """ user, of type [PublicKeyCredentialUserEntity](https://www.w3.org/TR/webauthn-3/#dictdef-publickeycredentialuserentity) This member contains names and an identifier for the [user account](https://www.w3.org/TR/webauthn-3/#user-account) performing the [registration](https://www.w3.org/TR/webauthn-3/#registration). Its value’s [name](https://www.w3.org/TR/webauthn-3/#dom-publickeycredentialentity-name), [displayName](https://www.w3.org/TR/webauthn-3/#dom-publickeycredentialuserentity-displayname) and [id](https://www.w3.org/TR/webauthn-3/#dom-publickeycredentialuserentity-id) members are REQUIRED. """...