Re: [webauthn] username and display name should not be mandatory (rp, challange either) and OS UX should be simplified if not present (#1915)

some questions:
- "no one wants to discuss" I mean, who are you to know this? and where to discuss, I mean actual RPs?
- did you make a working example? I created back then an actually working implementation without any libraries, pure js, pure java, pure math, worked on apple, android, windows (with face id and fingerprint)
- there are 2 challenges in create options and get options, I talked about create options of course:
https://www.w3.org/TR/webauthn-2/#dom-publickeycredentialcreationoptions-challenge

so tell me, why do we need to create in js a random number for this, if there is practically no attestation logic we want or even if we want, apple simply does not implement it? why is it REQUIRED? I mean all you actually need are the code below, and PLENTY of other stuff you must include with blanks or default values that 99,9999% will use but are not default in the specs... the real deal is generating the PID on server, giving by creation, choosing algo, then by get give a random challenge and check the signature later on server with the public key... it would also be nice if someone who actually wants to be this widespread provided the MOST simple code needed, without libraries... I mean I even had to write derToRaw() functions etc... getting info out of signature is a nightmare... it could be EXTREMELY SIMPLE code on client and server... it is not that complicated, I did it in js and java, but I can tell you now that an avergae RP will not want this and even if wanted, not capable, and not because it is that complicated but because the very simple stuff was made overly complicated with design horrors... I mean next time a good test: gather 10 RPs and if they cannot do this in a day and have a joyful face at the end of the day and practically no questions, THEN and ONLY THEN it is OK... I mean you can write NOTEs in the specs... I could make this working in 2 weeks alone, with wonderful understandable specs for the 99,9999% of RPs... but actually I think even if usernames and other shit disappeared and good notes and good example codes, this is the SMALLER part where I wanted to help you with my actual RP implementer experience... the BIGGER problem is backup... I think you should find a backupable format and derice ECDSA keys from them, there is an RFC for it and of course you just have to check out parts of bitcoin stuff:
https://www.rfc-editor.org/rfc/rfc6979.html
the whole model is bad because if it wants to win, it has to be backupable... I mean passkey is not really secure if you have another system where you recover with gmail... then it is just hokus-pokus

function getPkcCreateOptions(pid) {
    return {
        //user is passkey holder
        user: {
            //passkey id (PID) created on server, should not have personally identifying information
            id: _base64UrlToArrayBuffer(pid),
        },

        //only ecdsa 256 (rsa option means more complex code)
        pubKeyCredParams: [{type: 'public-key', alg: -7}],
    }
}

function getPkcRequestOptions(challengeArrayBuffer) {
    return {
         //the random dynamic server challenge that will be signed over with the passkey and returned to server along with the PID and signature
        challenge: challengeArrayBuffer,
    };
}

-- 
GitHub Notification of comment by r-jo
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1915#issuecomment-1835784168 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 1 December 2023 09:45:35 UTC