Re: [webauthn] Adds optional transport hints to CredentialDescription

@vijaybh wrote:
> Should there be some addition to the processing rules for 
`getAssertion` mentioning how to potentially use this?
@leshi replied: 
>  I did think a bit about it and looked at the processing rules as 
they are right now. I didn't find a spot that really resonated with 
me. Also, since the transports are just hints -- I thought maybe it 
was okay to omit mention of them from the processing rules.
@vijaybh replied:
> About the processing rules, it seems to me that the transport hints 
don't really make sense in the excludeList (or can you think of a way 
to use them there?) so I wonder if we could say something about using 
the transport hints to inform the filtering process in step 7 of 
section 4.1.2 (i.e. the getAssertion section).

I tend to agree with this suggestion regarding the filtering process 
in `getAssertion` processing rules. I also note U2F does not say 
anything specific regarding the use of the `transports` member of 
`RegisteredKey` during a register operation.  

For a `u2f.sign()` request (equivalent of `getAssertion()`), this is 
what is noted in the processing rules...
> When the RP provides the transports value for any RegisteredKey, the
 client MAY treat that value has a hint about which transports to 
prefer for the key handle. The client MAY also use the transports as a
 hint about user interface, if the client presents any. Irrespective 
of whether the RP sets any transports value for any RegisteredKey, the
 client SHOULD send each key handle over all transports supported by 
the client. 

Perhaps WebAuthn should say at least the equivalent, if the 
"Transports" hints notion is essentially the same as in U2F?


@vijaybh wrote:
> I wonder what adding "internal" as a transport would do that 
omitting the transport hint doesn't. I would assume the client already
 knows its internal authenticators and does not need hinting for them.

I tend to agree with this.  Also, we removed almost all occurrences of
 the term "external" from the spec, so I wonder whether the proposed 
ExternalTransport enum should just be termed "Transport" as in U2F  
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html.
  And if the RP omits the Transport hint, then it is presumed the 
underlying "platform" can figure things out. 

I also note that U2F allows for a authenticator to be reachable over 
more than a single transport...
```
enum Transport {
    "bt",
    "ble",
    "nfc",
    "usb"
};

typedef sequence<Transport> Transports;
```
..e.g., a smartphone-based authnr might work via either BT or NFC say.
  Might we desire the same in WebAuthn?





-- 
GitHub Notification of comment by equalsJeffH
Please view or discuss this issue at 
https://github.com/w3c/webauthn/pull/194#issuecomment-246521175 using 
your GitHub account

Received on Monday, 12 September 2016 22:53:22 UTC