Switch from a cookie to credential management

[phistuck]

Mandating cookie usage to confirm to the issuer that the user is logged in sounds like a step backwards considering the web platform already has a credential management API/web authentication API What about using credentials saved via the credential management API/web authentication API instead of cookies? Note - I am not talking about sending the actual username/password, of course. I am not familiar enough with how the API works to say for sure, but I imagine there are other types of credentials (a token or similar perhaps) that can be saved as well and those can be used

[dickhardt]

We might have called it out sufficiently, but we hope to extend authentication to the issuer to include a FIDO 2 / Passkey exchange.

We had it in an earlier draft, but took it out to align others on all the other aspects of the protocol.

If the issuer has credentials for the user identified by the email, it would return something like:

{
  "error": "authentication_required",
  "webauthn_options": {
    "publicKey": {
      "challenge": "base64url(challenge)",
      "rpId": "issuer.example",
      "allowCredentials": [
        {
          "type": "public-key",
          "id": "base64url(credentialId1)",
          "transports": ["internal","hybrid","usb","nfc","ble"]  
        },
        {
          "type": "public-key",
          "id": "base64url(credentialId2)"
        }
      ],
      "timeout": 60000,
      "userVerification": "required"
    },
    "binding": {
      "request_token_hash": "base64url(sha256(request_token))"
    }
  }
}

the browser would do all the necessary checks and get a gesture from the user and return something like:

{
  "request_token": "eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVC...",
  "webauthn_response": {
    "id": "base64url(credentialId1)",
    "type": "public-key",
    "rawId": "base64url(credentialId1)",
    "response": {
      "authenticatorData": "base64url(...)",
      "clientDataJSON": "base64url(...)",
      "signature": "base64url(...)",
      "userHandle": "base64url(opaqueUserHandle)"   
    }
  }
}

and then the issuer would return the SD-JWT

Was this what you were thinking?

This allows an RP to take advantage of passkeys without having to write or manage passkeys.

[phistuck]

Passkeys are one scenario, sure, but I was thinking of a normal login scenario like when you go to x.com and the browser asks you whether you want to log in, you confirm and it logs you in without entering details. That means the browser either has your credentials, or some token/similar and that can be used to log in. So using that kind of saved credential instead of cookies

[dickhardt]

Cookies and passkeys (or a relative of them) are the ways to login to a site if you are entering a password or OTP.

[stefan2904]

Is this related to DC API work? Or not, because its managed by the browser alone?

It also reminds me of FedCM..

[dickhardt]

DC API?

[fkj]

If there is a FedCM credential (an IdentityCredential) available for the email account, I don't see why it couldn't be used as an alternative to a cookie/WebAuthn credential.

@stefan2904 Using the Digital Credentials API would probably look something like asking for a verifiable credential that proves the user is in control of the email account. But this would work in a significantly different way than the current proposal, since the issuer is not directly involved. If someone had appetite, they could probably write up a version of the flow that uses DC API for steps 1 and 2, then skips directly to step 5 (presentation). But again, this is a significant departure from the current proposal since it involves a different architecture and credential format.