W3C home > Mailing lists > Public > public-webauthn@w3.org > March 2017

CredMan Credential Scoping and Webauthn

From: Mandyam, Giridhar <mandyam@qti.qualcomm.com>
Date: Wed, 8 Mar 2017 23:42:46 +0000
To: "public-webauthn@w3.org" <public-webauthn@w3.org>
Message-ID: <8715e06de6b24ae09911c4c5d099ef24@NASANEXM01C.na.qualcomm.com>
Apologies in advance - I am still not clear on how WebAuthn can be cleanly integrated as an additional credential in the Credential Management API (https://www.w3.org/TR/credential-management-1/). I'll focus on what I understand to be the actual scoping of the credential.

Current Webauthn Specification states under definition of RP ID:  "Scoped credentials can only be used for authentication by the same entity (as identified by RP ID) that created and registered them. By default, the RP ID for a WebAuthn operation is set to the current settings object's origin. This default can be overridden by the caller subject to certain restrictions ..."

Regarding 'certain restrictions',  if we go to Sec. 4.1.2 of Webauthn, under Step 4 of UA procedures it states: 

" If the rpId member of options is not present, then set rpId to callerOrigin. Otherwise,

	1. Let effectiveDomain be the callerOrigin’s effective domain.
	2. If effectiveDomain is null, then reject promise with a DOMException whose name is "SecurityError" and terminate this algorithm.
	3. If rpId is not a registrable domain suffix of and is not equal to effectiveDomain, reject promise with a DOMException whose name is "SecurityError", and terminate this algorithm.
	4. Set rpId to the rpId."

So RP ID by default is the webpage origin unless overridden to be the effective domain, based on my interpretation.  {Note:  my understanding of effectiveDomain may not be accurate - in this case I am assuming effectiveDomain is not the FQDN.}

Now if we look at sec. 6.1 of CredMan (https://www.w3.org/TR/credential-management-1/#security-cross-origin-leakage), the following guidance is given:

"... As a compromise between annoying users, and securing their credentials, user agents: ...

3. MUST NOT offer credentials to an origin in response to get() without user mediation if the credential’s origin is not an exact match for the calling origin. That is, Credential objects for https://example.com would not be returned directly to https://www.example.com, but could be offered to the user via the chooser. "

So if Webauthn were to be an acceptable credential under CredMan, then would the 'chooser' still be required for scoping?

-Giri


Received on Wednesday, 8 March 2017 23:43:21 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:25 UTC