Package com.iizix.server.user.passkey
package com.iizix.server.user.passkey
- ClassDescriptionThe authenticator data of WebAuthn (section 6.1 of the specification), decoded from the bytes the authenticator signed (CC-LOGIN-L8-PASSKEYS): the hash of the relying party ID, the flags, the signature counter, and - in a registration - the attested credential data with the new credential's ID and public key.A decoder for the CBOR (RFC 8949) a WebAuthn authenticator sends: the attestation object, the credential public key in COSE form and the extensions of the authenticator data (CC-LOGIN-L8-PASSKEYS).The public key of a passkey in its COSE form (RFC 9052, RFC 9053), as the authenticator sends it in the attested credential data and as the server stores it (CC-LOGIN-L8-PASSKEYS): decoded, checked, and turned into a key of the Java platform that verifies the signatures of the authenticator.The challenges of the passkey ceremonies that are under way (CC-LOGIN-L8-PASSKEYS): made by the server from its secure random source, kept in the memory of this server only, bound to the client session that asked and to the kind of ceremony, valid for one answer and for a limited time.The kinds of ceremony.A challenge under way.The refusal of a passkey credential or of a passkey request (CC-LOGIN-L8-PASSKEYS).The passkey ceremonies of the server (CC-LOGIN-L8-PASSKEYS): the options a ceremony starts with, the verification it ends with, and what the server keeps in between - the challenge, the sign-in that waits for a passkey, and what a client reported about itself.A verified sign-in with a passkey.What a client reported about itself.The refusal of an answer without a request: no challenge is under way for the client session, it was answered already, or its time ran out.The refusal of a registration for a user who has the most passkeys a user may have (
SigninResult.PASSKEYS_NOT_AVAILABLE).A sign-in that waits for its passkey: the password was accepted, nothing is recorded.The passkey settings of an application (CC-LOGIN-L8-PASSKEYS), resolved from the custom application settings that exist already: the application's own (customAppof its module project settings) over the ones of the server environment it runs in (customAppof theserverConfigEnv).The passkeys in the server database (CC-LOGIN-L8-PASSKEYS): the tablesIZS.USER_HANDLESandIZS.USER_CREDENTIALSofcreatePasskeyTables.sqlbeside this class, created here at the first use on a database of any age - the server'screateBaseTables.sqlruns on an empty database only (the model is the load balancer'sDBLoadBalancer.createTables).The verification of the two WebAuthn ceremonies as the specification's sections 7.1 (registering a new credential) and 7.2 (verifying an authentication assertion) define it, for passkeys (CC-LOGIN-L8-PASSKEYS).A verified assertion: what the credential record is updated with.The assertion a client sent, decoded and not yet verified: what is needed to find the credential it names.What the server expects of a ceremony.A verified registration: the new credential.The three.well-knownfiles that tie applications to the domain of their passkeys (CC-LOGIN-L8-PASSKEYS), served by this server for the domains it is the host of - for a relying party ID that is a parent domain, the web server of that domain serves them:/.well-known/apple-app-site-association: the iOS applications that may use the passkeys of the domain (webcredentials), fromsignIn.passkey.iosApps;/.well-known/assetlinks.json: the Android applications that may (delegate_permission/common.get_login_creds), fromsignIn.passkey.androidApps;/.well-known/webauthn: the origins that may use the relying party ID (WebAuthn related origin requests), fromsignIn.passkey.relatedOrigins.A passkey as the server stores it: one row ofIZS.USER_CREDENTIALS(CC-LOGIN-L8-PASSKEYS).