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

Re: [webauthn] include public key in result from create()

From: Angelo Liao via GitHub <sysbot+gh@w3.org>
Date: Fri, 15 Sep 2017 21:19:25 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-329906569-1505510354-sysbot+gh@w3.org>
The argument for removing the publicKey is the following: The client shouldn't have to worry about key parsing. Although this adds a complexity to the server side, most servers are already equipped to handle complexity. @equalsJeffH also pointed out that we had some discussions regarding pushing the complexity to the server side and can add more explanation. By putting publicKey in the blob, it forces people to parse it and provide additional security protection. 

The below ae the minutes around the description about removing public key (Actually I think I wrote down the minutes here so I wish I wrote it down more comprehensively): 

> https://github.com/w3c/webauthn/issues/321
> We will start by looking at 321 
> Vijay is leading the discussion for PR 321 
> Vgb: we will look at the diff first instead of going through all of the changes 
> Dirk: the public key is no longer returned by makeCredential 
> Now the returned object from makeCredential is only clientDataJSON and attestationObject 
> The logic behind the change is that the client shouldn't have to worry about the key parsing. It'd be best if only a blob is returned. 
> Another change is regarding U2F attestation format 
> Alexei: credential ID is missing 
> Vgb: he will ensure the Cred ID is available there and will fix this problem later 
> Richard Barnes: I think the logic is backward 
> Richard's main concern is that there are certain common attributes cross all authenticators. 
> JeffH: there have been discussions where we decide to push the complexity back to the server side 
> Richard: I agree that for the browser, it should just give back the attestation blob 
> Vgb: what we learned is that most servers are already equipped to handle the complexity 
> Richard: the assumption of Vgb"s argument is all the relying parties care about attestation 
> Vgb: however, we have to think about what the solution to this problem is. Which step will take care of the complexity, the RP, browser, authenticator? 
> Dirk: the browser should take care of the complexity. Another point is that we shouldn't have to worry about making a distinction between server and the frontend JS. 
> Because whether server and JS script takes care of the compleixty is going to shift over time 
> Vgb: we are looking at figure 3 
> All parts of the attestation data is standard component 
> Alexei: why the attestation format, data, and statement is in binary format instead of JS object 
> ... U2F attestaiton has additional complexity because it doesn't have AAGUID, counter, etc. 
> <jeffh> The Concise Binary Object Representation (CBOR) data format (RFC7049) implemented in pure JavaScript: https://github.com/paroga/cbor-js 
> Vgb: the complexity is either going to be on the authenticator or the RP either way. 
> wendy, do you mean who is at the F2F 
> Vgb: one point made in the past: should we make the API a bit opninate to force people to parse attestation to have additional secuirty protection 
> For RPs who don't care about attestation, they don't have to parse it. 
> Richard: let's land 321 first. I and Dirk will look at it and see if we can make it better 
> <jcj_moz> scribenick: jcj_moz 
> nadalin: We're going to merge 321, and then people can comment on it, and we'll resolve the comments in WD-05. We can merge this and put out WD-04. 

GitHub Notification of comment by AngeloKai
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/557#issuecomment-329906569 using your GitHub account
Received on Friday, 15 September 2017 21:19:17 UTC

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