Clean up extensions section #130
Conversation
- Resolve inconsistent wording in different parts of the section: fix places that incorrectly suggested extensions cannot be used with makeCredential, and resolve conflict between wording that said client arguments are required vs. not. - Treat implementations that choose to pass through extensions as a first-class citizen by requiring that extensions be defined to allow for this. Fixes #97. - Fix all the predefined extensions to conform to the updated guidelines. - Minor issues: AAGUID should be binary not string (see #61, fixes #51) and encode true as Boolean in CBOR instead of forcing it to integer value 1.
| processing. | ||
| An extension defines up to two request arguments. The <dfn>client argument</dfn> is passed from the <a>[RP]</a> to the client | ||
| in the {{getAssertion()}} or {{makeCredential()}} call, while the <dfn>authenticator argument</dfn> is passed from the client | ||
| to the authenticator during the processing of these calls. |
There was a problem hiding this comment.
this parag has always been ambiguous (to me, anyway) as to whether it is possible for an RP to pass an authenticator argument that the client then simply passes on to the authnr. If that was an original intention of the definition of extensions, AND we intend to continue that, then lines 1453-1455 ought not be deleted. Otherwise, carry on :) tho clarification is perhaps appropriate.
There was a problem hiding this comment.
Lines 1453-1455 are not deleted, they are just moved down (see 1462-1464 in the green, below). Lines 1474+ explicitly say that what you ask is true, except for transcoding (the RP passes a client argument in JSON, it gets sent as an authenticator argument in the corresponding CBOR). Perhaps we can do a round of editorial improvements later?
There was a problem hiding this comment.
thanks for clarification, sounds fine.
- Rename "signature extension" to "authentication extension" (will be added to glossary in #131) - Pre-defined extensions recommended (but not required) for implementation by clients - Require extensions to update either ClientData or authenticatorData, update authenticator selection extension to obey this rule - Clarify that authenticator arguments are sent to the authenticator as a map, not as bare values
|
LGTM |
places that incorrectly suggested extensions cannot be used with
makeCredential, and resolve conflict between wording that said client
arguments are required vs. not.
first-class citizen by requiring that extensions be defined to allow for
this. Fixes Clarify when an extension may be ignored by user agent #97.
guidelines.
and encode true as Boolean in CBOR instead of forcing it to integer
value 1.