AuthZ Biweekly Meeting - 8-Aug 2023

[bumblefudge]

8 Aug

PRs to refine/move to close

• multidid-pkh
  • merged
  • follow-up to mandate all chainIDs be integers for EIP-155 only
  • Juan to open upstream did:pkh PR for tacking on public keys to query params of did URLs where not atomic to CAIP-10 itself

Ongoing issues/topics

• varsig#11
  • previous discussions about using WebAuthN's PRF function (which creates arbitrary entropy off your webauthn credential) versus generating token externally and just
    • downsides to using webauthn's native PRF: 1.) still an extension, not in most browsers yet (just firefox!) 2.) puts keys generated into readable memory (becomes extractible)
    • alternate approx: put digest or arbitrary message into challenge field, put a nonce in the nonce, get webauthn-reliant signature back (not the authN signature, a new signature made by that token)
    • consensus - some text specifying we're doing the latter here, not the former
  • Joel: using CID as challenge (32 bytes), but don't we also need more inputs
    • challenge length recommended to be >=16bytes , so could be a CID+anything
    • Chunny: constrain choice of hashes (blake512, e.g., couldn't work); CIDv1 too open
      • challenge length --> choice of hash; identity hash --> doubles length; although I suspect FIDO spec will hash all inputs down to 32 bytes anyways as digest, will check and experiment
    • Joel: hard to get recovery bit when using ECRecover/secp keys
      • Chunny: public key returned by authN ceremony but needs to be stored somewhere;
      • Joel: don't need to store it if credential_get can have the recovery bit somewhere in it; YubiKey implementation, for ex., seems to stash a few bytes of pub key in other fields so that public key is recoverable on each session from, e.g. SIWE
        • this would mean full AuthN ceremony only needs to be done at registration and nothing stored between sessions
        • Hugo mentioned on the UCAN call that Chrome, Android, and iOS not handling this the same way, tho; recovering public key could get dodgey across platforms if so
  • chunny: PR still draft, has TODOs
    • joel: will review in a few weeks
    • other todo: note about replay attacks necessary? Rust implementation guidance for webauthn mentioned holding onto authentication or attestation bits for length of the session in some kind of cache?
      • joel: but if it's a capability i'm not sure it's as big a risk...
      • chunny: invoke a cap twice? not so bad
      • aaron: no risk to replaying something idempotent

Next Steps