- From: Mandyam, Giridhar <mandyam@qti.qualcomm.com>
- Date: Thu, 9 Jun 2016 17:54:11 +0000
- To: "Hodges, Jeff" <jeff.hodges@paypal.com>
- CC: W3C WebAuthn WG <public-webauthn@w3.org>
> hm, I don't understand why one would need to design this as these two extensions in order for the platform (UA+OS+Authnrs) to be able to apply user preferences -- might you explain? I can collapse the request and response into one extension, if the group agrees that this can be a pre-defined extension. This would be consistent with the transaction authorization extension definition (https://w3c.github.io/webauthn/#extension-txauth), which in my interpretation is an example of a "prompted" extension. I am perfectly OK with that. I personally don't find the text on the transaction confirmation so easy to ready, in that it does not clearly outline the sequence of steps that should occur. My interpretation of the proposal in https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0049.html was that an extension should not be added by the authenticator without a corresponding request from the RP. I took this to mean that RP must add an extension request to the makeCredential() method for a prompted extension. My intention in separating the request and response was to make clear that the request extension must first appear in makeCredential() before the response extension can be added to attestation/assertion. But maybe this sequence would be obvious to anyone who reads the spec. -Giri -----Original Message----- From: Hodges, Jeff [mailto:jeff.hodges@paypal.com] Sent: Thursday, June 09, 2016 8:45 AM To: Mandyam, Giridhar <mandyam@qti.qualcomm.com> Cc: W3C WebAuthn WG <public-webauthn@w3.org> Subject: Re: Proposal for a Trusted Location Extension On 6/7/16, 5:26 PM, "Mandyam, Giridhar" <mandyam@qti.qualcomm.com> wrote: >JeffH wrote: > >>does this replace the proposed "Opaque data" extension in >>https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0001.html >>..or is it in addition to the above? > >Consider it an addition. I am still trying to work on an opaque data >extension that can satisfy some of the (valid) concerns raised >regarding user privacy. > >> So this is actually two extensions, where the first allows an RP to >>determine whether an authnr supports the second extension, yes? > >Yes. I wrote it this way in order to indicate at which point the >client could filter out any request from the RP that was not consistent >with user privacy preferences. I personally am not convinced that >browsers implementing the Web Auth API will actually query permissions >from the user on a per-extension basis, but this extension was designed >to enable such fine-grained permission management. hm, I don't understand why one would need to design this as these two extensions in order for the platform (UA+OS+Authnrs) to be able to apply user preferences -- might you explain? thx =JeffH > >> Actually, I believe (IIUC) you can define this as a single extension >>-- the RP would simply request it, the indication of such a request >>would be sent down to the authnr by the UA+OS (if the UA+OS deigns to >>honor this extension request), and if the authnr supports it, the >>authnr includes the resultant extension data in its emitted >>`authenticatorData`. If the authnr does not support the extension, it >>ignores the authnr argument requesting it. The RP can tell whether the >>extension was honored by examining the returned attestation object or >>webauthn assertion. > >Agreed. I can revise accordingly if the group agrees to adopt. > >-----Original Message----- >From: Hodges, Jeff [mailto:jeff.hodges@paypal.com] >Sent: Tuesday, June 07, 2016 3:48 PM >To: Mandyam, Giridhar <mandyam@qti.qualcomm.com> >Cc: W3C WebAuthn WG <public-webauthn@w3.org> >Subject: Re: Proposal for a Trusted Location Extension > >On 6/7/16, 1:40 PM, "Mandyam, Giridhar" <mandyam@qti.qualcomm.com> wrote: >>Hello All, >>Enclosed is proposed text for a verifiable location extension. Note >>that this is bi-directional the RP must request the extension, and >>the authenticator should provide the associated location data only >>when requested (i.e. it is not ³unprompted² data). I can discuss this >>on the next conf. call on June 8. > >does this replace the proposed "Opaque data" extension in.. > > > https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0001.html > >..or is it in addition to the above? > >So this is actually two extensions, where the first allows an RP to >determine whether an authnr supports the second extension, yes? > >Actually, I believe (IIUC) you can define this as a single extension -- >the RP would simply request it, the indication of such a request would >be sent down to the authnr by the UA+OS (if the UA+OS deigns to honor >this extension request), and if the authnr supports it, the authnr >includes the resultant extension data in its emitted >`authenticatorData`. If the authnr does not support the extension, it >ignores the authnr argument requesting it. The RP can tell whether the >extension was honored by examining the returned attestation object or webauthn assertion. > >Does that make sense? > >HTH, > >=JeffH > > >> >>Verifiable Location Request Extension >> >> >> This extension allows a WebAuthn Relying Party to request an >>authenticator to add a verifiable location as extension data to either >>the packed attestation or assertion. >> >> >>Extension Identifier >> >> >> webauthn.loc-request >> >> >>Client argument >> >> >> Null >> >> >>Client processing >> >> >> This extension can only be used during makeCredential(). If the >>selected authenticator supports verifiable location, then the client >>MUST not prevent the extension from being returned in either the >>packed attestation or assertion. >> >> >>Authenticator argument >> >> >> If the authenticator supports extension selection AND supports the >>verifiable location, then the client MUST pass as an argument the >>extension identifier encoded as a CBOR text string. >> >> >>Authenticator Processing >> >> >> The authenticator SHOULD accept or reject the extension selection, >>and provide an indication to the client. If the authenticator rejects >>the extension, then the authenticator SHOULD NOT add verifiable >>location to the packed attestation or assertion. >> >> >>Authenticator data >> >> >> The authenticator SHOULD provide an indication of acceptance or >>rejection with a CBOR encoded integer value of Œ1¹ (indicating >>acceptance of the requested extension) or Œ0¹ (indicating rejection). >>Any returned values other than Œ1¹ or Œ0¹ would constitute rejection. > > > > > >> >>Verifiable Location Extension >> >> >> This extension allows an authenticator to add a verifiable location >>as extension data to either the packed attestation or assertion. >> >> >>Extension Identifier >> >> >> webauthn.loc >> >> >>Client argument >> >> >> No client argument required. >> >> >>Client processing >> >> >> No client processing required. >> >> >>Authenticator argument >> >> >> No authenticator argument required. >> >> >>Authenticator Processing >> >> >> The authenticator SHOULD only add this extension to a packed >>attestation or assertion if the relying party has requested it via the >>webauthn.loc-request extension. >> >> >>Authenticator data >> >> >> The authenticator data SHOULD be a CBOR-encoded type 5 map. >> >> >> >> >> >> > > > > >
Received on Thursday, 9 June 2016 17:54:43 UTC