- From: Hodges, Jeff <jeff.hodges@paypal.com>
- Date: Tue, 5 Jul 2016 23:25:10 +0000
- To: "J.C. Jones" <jjones@mozilla.com>
- CC: "public-webauthn@w3.org" <public-webauthn@w3.org>
> The following commits were just pushed by jcjones to > https://github.com/w3c/webauthn: > [...] > > * Remove distinctions between External and Embedded Authenticators> [1] > > * Change "WebAuthn Relying Party" to just "Relying Party" [2] Hi, Overall, I'm nominally ok with the above changes. Alhough I can see where the above change [1] may help web developers comprehension, and [2] reduces wordiness, I do have some concerns.. 1. I do not think we should entirely loose the "embedded/bound" and "external/portable/roaming" notions. These concepts will be likely be useful to platform developers (see also the thread entitled "use cases"). in particular, this text may be important to some readers.. -Note that an external authenticator may itself contain an embedded authenticator. For example, consider a smart phone that -contains a scoped credential. The credential may be accessed by a web browser running on the phone itself. In this case the -module containing the credential is functioning as an embedded authenticator. However, the credential may also be accessed over -BLE by a user agent on a nearby laptop. In this latter case, the phone is functioning as an external authenticator. These modes -may even be used in a single end-to-end user scenario. One such scenario is described among the use cases below (in -[[#authentication-external]]). I would be fine with capturing such information in an impl-considerations section or an appendix of some sort. An example of such a section is.. <https://tools.ietf.org/html/rfc6797#section-12> As for [2], I can live with using the unqualified term "Relying Party" in many places in the text, however, we have been hearing literally for years, especially from the Fed'd Identity Mgmt community, how confusing they find the use of the unqualified "Relying Party" term. Over the years I've observed many instances of unnecessary misunderstanding and getting-bolloxed-up due to use of imprecise/ambiguous terminology. Thus, if we can't simply use "WebAuthn Relying Party" everywhere, then I suggest editing the new RP definition to be like so.. WebAuthn Relying Party Relying Party The entity whose web application utilizes the Web Authentication API to register and authenticate users. See Registration and Authentication, respectively. Note: While the unqualified term Relying Party is also used in other contexts (e.g., OAuth, SAML, X.509, etc.), an entity acting as a Relying Party in one context is not necessarily a Relying Party in others. For example, in an identity management deployment, WebAuthn may be used as a user authentication mechanism at the Identity Provider, who thus is also acting in the WebAuthn Relying Party role. Additionally, within each major section I'd use the "WebAuthn Relying Party" term on first use and "Relying Party" otherwise. I think it's really important we make this extra effort to disambiguate the terms. Also, we /could/ use the acronym "WRP", say, rather than the spelled-out unqualified "Relying Party" term. thanks, HTH, =JeffH ps: I'm fine with 'Move attestation type definitions to their own top-level section'.
Received on Tuesday, 5 July 2016 23:25:46 UTC