Re: [webauthn] Add a way to use webauthn without Javascript (#1255)

I think that a QUIC "pluggable authn" is along the same lines as what I was thinking about.

@equalsJeffH can you provide a link or some more information on the "pluggable authn mechs" discussion?

If the authentication happens in the QUIC or HTTP/3 protocol, then that means that an HTML form is NOT used to do authentication. The authentication method is decoupled from the user's interactions with the HTML page. (The browser does not have to wait for the user to click an anchor or submit a form.) The browser may still interact with the user, for example to ask the user which credential or login to use with the RP, but this interaction is between the browser and the user, it is not a custom interaction between the RP and the user. (Performed by the RP's web page, including custom HTML and javascript.)

This is great. It gives the browser the tools it needs to innovate.

For browsers and websites that do not support xxx new technology (QUIC, etc.), there should be an easy way to shoehorn the user authentication into existing technologies. (i.e. into HTTP or HTML, etc.)

The HTML changes to allow for user authentication should NOT require the use of an HTML form, nor an HTML anchor. Although a form or anchor can ALSO be included in the HTML. For cases where an RP wants to provide custom actions (i.e. a redirect uri, etc.) or an on-page login interface for users. It allows an RP to provide users a more familiar interface. (i.e. users can login by interacting with the HTML page.)

The "pluggable" user authentication settings data (i.e. the webauthn settings) should be put into a special non-visible element in the HTML page header. Probably a meta tag or a link tag. (Alternately, the webauthn settings can be put in a separate JSON file on the server, and the meta or link tag can reference that file. In the href attribute, etc.) This allows the browser to retrieve the webauthn settings and perform webauthn (or some other future protocol) without requiring javascript, or that the user interact with the RP through the HTML page, etc.

Each user authentication method would need to define its own settings in the HTML.  (A "pluggable" user authentication system needs to support multiple user authentication methods. i.e. other options besides "webauthn". The methods could be called a "protocol", or an "RP service", etc.)

Example:
<pre>&lt;link rel="capis-act" href="/user_auth_config.json" capis-config='
"rpInfo": {
  "displayName": "ACME Corporation",
  "siteLogo": "/images/logo.png"
},
"serviceList": [
  {
    "protocol":"webauthn",
    "endpoint": {"http_method":"POST",
      "uri_address":"/exampleapp/webauthn/finish_assertion",
      "parameterList": [{"name":"user_auth_param", "type":"JSON"}],
      "assertion_format": "assertion format1",
      "creation_format": "creation format1"
    },
    "customData": {
      "exampleapp_request_id":"3a74f2b4-cff0-4f50-8076-2f5532a0d6f3"
    },
    "challenge": "WwdPrNbUcI1034qZ9LYks32ZPezDLZSieFI9f6NaZZs",
    "assertionOptions": {
      "propertyName": "assertionInfo",
      "publicKey": {
        "challenge_old": "WwdPrNbUcI1034qZ9LYks32ZPezDLZSieFI9f6NaZZs",
        "allowCredentials": [{ "type": "public-key", "id": "Pzy_hxuR849qZbLAE8Vr4U3KPiIN6W10ssJOR55BMZQ",
            "transports": ["usb", "nfc", "ble", "lighning", "internal"] }],
        "userVerification": "preferred",
        "timeout": 120000,
        "extensions": {"loc": false }
      }
    },
    "creationOptions": {
      "propertyName": "creationInfo",
      "publicKey": {
        "challenge_old": "WwdPrNbUcI1034qZ9LYks32ZPezDLZSieFI9f6NaZZs",
        "rp_old": {"name": "ACME Corporation"},
        "user": {"id": "bYq3-Uk0J3xMt", "name": "alex.p.mueller@example.com",
          "displayName": "Alex P. Mueller"},
        "pubKeyCredParams": [{ "type": "public-key", "alg": -7 }, 
            { "type": "public-key", "alg": -257 }],
        "authenticatorSelection": {
          "authenticatorAttachment": "platform",
          "residentKey": "required",
          "requireResidentKey": true,
          "userVerification": "preferred"
        },
        "timeout": 360000,
        "attestation": "none",
        "excludeCredentials": [],
        "extensions": {"loc": false }
      }
    }
  }
],
"nonceIssueTime":1533064012,
"nonce":"WwdPrNbUcI1034qZ9LYks32ZPezDLZSieFI9f6NaZZs" '/&gt;
</pre>

Later in the HTML.
<pre>&lt;a href="/fallback/login.html" rel="capis-act" capis-config=' "serviceAction":"webauthn/login", "redirect_uri":"/page2.html" '&gt;Login Here&lt;/a&gt;</pre>

Notes:
1. The JSON in the "link" tag should be able to contain settings for multiple services. (user authentication or other types.) So it uses a "serviceList". This also makes it extensible for the future.
2. The "endpoint" property specifies everything about the RP endpoint, that receives the service request. (The URI, http_method, etc.)
3. The HTML page should contain settings for BOTH webauthn.get and webauthn.create. (Called "creationOptions" and "assertionOptions" in the example.) This gives the browser the most flexibility. (i..e It can choose to use webauthn.get or webauthn.create, in response to user demands, etc..)
4. Moved some webauthn properties around. Changed the old property name to end in "_old". The "challenge" was moved outside of both "creationOptions" and "assertionOptions", so it can be used by both. etc. (Also, "rp_old")
5. There could be some properties that are useful for all protocols. The "nonce" and a "nonceIssueTime" may be useful. (Can use the "nonce" instead of the webauthn "challenge".) HTML5 has settled on using the name "nonce".
6. The anchor will trigger the browser to perform the specified "service action". The JSON property "serviceAction":"webauthn/login", informs the browser to use the "webauthn" service to perform a "login". It does not tell the browser to do either the "webauthn_get" or the webauthn_create" action. The browser can make that decision on its own.
7. How the browser gets a new user_id. Either the RP's response to a "webauthn.create" should include a new "user_id". Or a new user_id can be reserved by the RP for the current connection/session/user, and provided in the webauthn settings. in base64url encoding. (i.e. creationOptions.user.id = "bYq3-Uk0J3xMt")
8. The "customData" property contains any data that the RP wants to be sent back to it. The browser is to copy the entire contents of the "customData" property into the request sent to the RP. (i.e. into the POST.) The "exampleapp_request_id" is an application-specific reference to server-side state.
9. The "assertion_format" of the endpoint specifies the transport format the endpoint requires for a webauthn.get request. (There should be a default value, so the example could remove that property.)
10. The POST to the RP will (most likely) have at least one parameter that is a JSON object.
The "assertionInfo" may be sent as separate parameter. (The parameter may be given a different name. By using "propertyName", etc.)

Example POST sent to the RP. "assertionInfo" may be sent as a separate parameter.
<pre>user_auth_json={
  "serviceAction": "webauthn.get",
  "customData":{"exampleapp_request_id":"3a74f2b4-cff0-4f50-8076-2f5532a0d6f3"},
  "assertionInfo": {
    "credentials": [{ // Allow multiple credentials, for a future extension?
      "id":"K3xM080fiCDCkv412SdQ6--982rRf9i6NtDY0Jkv-AJZaCH9-MNs-ijV2y2OXKbxjzD3rXR05rmGF_jGQnXyPQ",
      "response":{
        "authenticatorData":"xGzvgq0bVGR3WR0Aiwh1nsPm0uy085R0v+ppaZJdA7cBAAAANQ==",
        "clientDataJSON":"eyJjaGFsbGVuZ2UiOiJwa...",
        "signature":"MEUCIHw..."
      },
    }],
    "clientExtensionResults":{},
    "transports":["usb"]
  }
}
</pre>

-- 
GitHub Notification of comment by Garnac
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1255#issuecomment-559328199 using your GitHub account

Received on Thursday, 28 November 2019 03:34:33 UTC