- From: r-jo via GitHub <sysbot+gh@w3.org>
- Date: Sat, 19 Aug 2023 05:37:44 +0000
- To: public-webauthn@w3.org
I really dont have time for this but you simply state logically false statements! You do not even realize there are 3 possibilities for the 2 username fields or whatever pass manager labels you want relying parties to micro manage or suggest: 1. required in the specs as of now 2. optional 3. deleted You repeatedly argue against 3. (and even if was possible and desirable wit ha radical rethink, I actually suggested 2.) Let us see you last answer statement by statement: A: "WebAuthn doesn't need the usernames internally" - thank God we agree, check B: "human-comprehensible labels are still needed for human end-users to understand and what each passkey is for" - no, only if there are multiple accounts to the same web domain... if you have one car, you dont label your car keys, if you have one identity card, you dont label them either, if you have one passkey for each domain in you pass manager (for simplicity, lets say you use apple that sync to your ipad and mac from your iphone in keychain and we consider apple pass manager) than the label is not needed since you have one entry for xyz.com - I said 5x that we should consider one account per domain the normal case, it is just a kind of a mental attitude we still have to think about multiple accounts of course - if there are multiple accounts, you are right it is better to label them but the question is, in this abnormal state, who should label them... last time I checked you can change these labels in the Google Pass Manager as user as you wish and happily overwrite any inital labels that were provided by the relying party with these discussed 2 username fields... the relying party will have no notification or whatsoever, which is totally ok because these labels in the pass manager are actually not the website owners responsibility to manage - so yes, in the abnormal case of multiple accounts a user better do some labeling... it MAY be convenient at first sight for both the website owner and the user if there is some kind of username/email in the system (which is not always the case and I think it should not be the case and the EU DMA may force website owners to provide usernameless accounts in the future per defaul with email and such opt ins...) but I would say it is just postponing the "problem" or responibility that actually the user has to manage these labels and it may suggest wrongly to website owners that they have to carry on with username-management in the passkey system too, even if it is logically usernameless... but it is a discussion between 1 and 2 not 2 and 3! I just say in my opinion actually 1 would be best but I happily compromise to 2... I am not the API designer so let us see how web site owners and users manage with these fields but those website owners who want to opt out of this should be allowed to WITHOUT a hacky way of setting fields to blank or current time millis or whatever... C: "your original ask is based on a false premise" , "if they were optional, then the client UI would have to have more steps than if they were set" , "the client would have to ask the user for one if the RP doesn't" - simply NOT true - for the normals case of one account, the UX would be "use your passkey for xyz.com", easier cannot be - for the abnormal case of multiple accounts, the UX would be more complicated as it is now, showing account chooser - what you are referring to is not part of the normal case and not part of webauthn process... and again, arguing against 1. not 2. which is very annoying, really! with 2. each and every relying party who wishes to label the pass manager through these fields CAN, and those who do not wish, they can do that too... again, I just silently say that 1. is the best design since it forces website owners and everybody to think the logically correct way but we discuss 2. here and your arguments are against 1 - so this extra step you mention is not part of the whole process, it occurs if a relying party decides not to label the pass manager fields with some username or email (because they may not have any) and the user is not happy with 1,2 or timestamps... in this case a user can and should re-label them but it is outside of the webauthn process and it is possible even now... and you cannot sweep this case under the rug since it MUST happen by websites who simply do not have usernames, moreover, we may encounter more and more such websites... it will be very messy if each and every website HAS TO come up with some own labeling logic instead of a well established pass manager behavior of labeling them 1-timestamp, 2-timestamp or such... D: "The RP is better equipped than the client to choose and remember a suitable "account label"" - not true, it may seem to be in the case of usernames/emails but the user is as equipped as the RP to label multiple accounts and it is better if they do what their responsibility is... with usernameless accounts ONLY the user is well equipped to label the accounts - messing with more platforms instead of getting syncing right is another problem I see that will bury this kind of passkey webauthn in the end, so you bring up another bad design that there will be no single pass manager... but in this case too, having the normal case of one account per domain avoids problems, and again, you argue against 1 and not 2... please let it be my problem to decide if I want to micromanage those users who create multiple accounts in my domain, with number 2: all relying party who think your way can happily micromanage their users... I simply do not care and CANNOT care for users that create multiple accounts on multiple platforms for a usernameless website how they label their multiple pass managers... even if I had emails and such, I would not care to use the optional fields and the users should label their multiple accounts in their multiple pass managers... but again, please argue against 2 not 1 E: "I fully agree that choosing suitable values for user.name and user.displayName in a username-less application is difficult" - no, it is not difficult, it is something a RP should not do, and if you force us to do with BAD API design, then users will se blanks, timestamps, 1,2,3 and A,B,C and domain names and whatever popping up instead of some unified way of their pass manager - the pass manager should choose how to handle this and so the users will have a unified way across web domains who CANNOT or WILL NOT care about the abnormal case of multiple accounts Please RE-THINK: - do not argue against 1, 1 vs 2 is another discussion, we discuss 2 vs 3 - usernameless RPs cannot handle username fields properly, it is not a challenge for them but it is where the problems of the BAD design opos up and will keep popping up - it is possible (and for some usernameless websites a MUST "thanks" to the bad design) to handle these required fields with blanks, timestamps etc. (but for example not possible to use enumeration since users can delete pass manager entries so only a pass manager can realyl handle enumerations) but it is UGLY and HORRIBLE and a DESIGN SMELL - moreover, pass manager implementations will be ugly too... there is an EXTRA step (account chooser) in the pass managers now because of this DESIGN HORROR... should pass managers supress these fields until there is only oe account per domain? should they suppress them when the REQUIRED field comes with a blank or should they suppress them when it is a timestamp? they should definitely suppress them when the RP wants to omit these fields which the RP as of now cannot communicate to them... they should internally label them with 1-timestamp and show 1-timestamp and 2-timestamp or so if there is another passkey with different anonymous id to the same domain... but as of now the pass manager implementors always get these fields and they just build in extra texts and extra account choosing steps instead of "create your passkey for xyz.com" and "use your passkey for xyz.com" -- GitHub Notification of comment by r-jo Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1915#issuecomment-1684834712 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 19 August 2023 05:37:47 UTC