Potential problems with HTTP OPTIONS?

[paulbastian]

Filip Skokan at IETF 122:

A good web application framework will discern between a preflight and a non-Preflight request and give the dev an option to handle the non-preflight.

What this dance will do in a browser, since both the nonce-fetching and actual request is

1. OPTIONS Preflight for the nonce-fetch

2. nonce-fetch

3. OPTIONS Preflight for the actual request

4. actual request

The js client has no access to the preflight response so there's no option to make the preflight the nonce-value vessel. Of course at the point the actual request's preflight the nonce must be incorporated in the request.

(meetecho messed up the list formatting)

fix: since both the nonce-fetching and actual request * are not "simple" requests

see "simple requests" https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS#simple_requests

[francis-pouatcha]

An alternative could be a dedicated GET /nonce endpoint. This endpoint would return a periodically updated, server-generated nonce (non-client-specific, protected by a server secret).

If this GET request qualifies as a CORS simple request (i.e., requires no custom headers for the fetch), it could avoid the preflight for the nonce fetch itself.

While the subsequent authenticated request (using the nonce and custom attestation headers) would still require its own preflight, this GET approach could potentially reduce the total number of requests, resulting to:

1. GET /nonce-fetch
2. OPTIONS Preflight for the actual request
3. actual request

[tplooker]

@panva I may be missing something here, but I'm not sure how using HTTP OPTIONS is any less efficient then using another HTTP verb in the nonce request like GET. Practically speaking if we boil this down to a simple sequence diagram, the proposal to use a HTTP OPTIONS based request would net the following.

sequenceDiagram
    participant WA as Web Application
    participant WP as Web Platform
    participant CI as Credential Issuer

    WA->>WP: Nonce request using fetch() with HTTP Options
    WP->>CI: Preflight HTTP OPTIONS request for CORS
    CI->>WP: HTTP Response to Preflight request
    WP->>WP: Evaluate CORS policy
    WP->>CI: Send nonce request using HTTP Options
    CI->>WP: HTTP Response to nonce request
    WP->>WA: Return HTTP response from nonce request 

Loading

Which yes does mean two HTTP requests are sent to get the nonce, but I dont think this can be avoided in any solution because of how the web platform works. Unless as pointed out we can get the nonce request to qualify as a simple request?

For example if the nonce fetching were instead based on an endpoint that is interfaced with using the GET HTTP Verb, wouldn't the following sequence diagram be what ensues?

sequenceDiagram
    participant WA as Web Application
    participant WP as Web Platform
    participant CI as Credential Issuer

    WA->>WP: Nonce request using fetch() with HTTP Get
    WP->>CI: Preflight HTTP OPTIONS request for CORS
    CI->>WP: HTTP Response to Preflight request
    WP->>WP: Evaluate CORS policy
    WP->>CI: Send nonce request using HTTP Get
    CI->>WP: HTTP Response to nonce request
    WP->>WA: Return HTTP response from nonce request 

Loading

[panva]

@tplooker https://mailarchive.ietf.org/arch/msg/oauth/nKdi0aeGymSMxkL51CmNgzbh8_g/

Summarizing, we should look for a different solution than OPTIONS on
existing endpoints because it conflicts with existing unrelated behaviours
(CORS). Any solution we consider that doesn't extend existing OAuth 2.0
responses should also likely stay within the confines of being a Simple
Request
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS#simple_requests
but
preferably we'll consider extending our existing protocol messages and
using their existing semantics before resorting to adding new endpoints.

[c2bo]

@panva, could you take a look at #110? That was the outcome of paul, justin and me discussing for another hour at EIC