Re: [webauthn] Add notion of forbidding resident credential creation (#1149)

NOTE: some have been thinking that this would be a change to WebAuthn only (no [CTAP]( since this change only affects how the browser selects eligible authenticators for that specific transaction.  

Actually, it is seeming to me that the above claim is not correct -- i.e., that CTAP is indeed also affected and will require changes:

Presently, CTAP only specifies specific behavior for `rk=true`. If `rtk` is false, whether or not we are creating a [client-side resident credential](, or a [server-side resident cred]( (aka "server credential"), appears to be implicitly left up to the authenticator.

E.g., present CTAP language is in Step 10 of [ CTAP's authenticatorMakeCredential() operation](

See also the [webauthn language wrt "requiring a resident key":]( ..and also the ["credential storage modality" section]( whose last paragraph says: 
> Note that a resident credential capable authenticator MAY support both storage strategies. In this case, the authenticator MAY at its discretion use different storage strategies for different credentials, though subject to the requireResidentKey option of create().

..note also that the above-menioned werbauthn language for [requireResidentKey]( says only this: 
> "If the parameter is set to true, the authenticator MUST create a client-side-resident public key credential source when creating a public key credential."

..thus leaving the `requireResidentKey=false` behavior up to the client platform and/or the authenticator (and given present CTAP spec language, it apparently is **_implicitly_** left up to the authnr).

cc: @christiaanbrand 

GitHub Notification of comment by equalsJeffH
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 30 January 2019 22:13:40 UTC