See also: IRC log
<weiler> scribenick: vgb
nadalin: Could discuss open PRs.
Jeff and Alexei not here yet, so maybe skip for now.
... did anyone review?
vgb: I did - look at Jeff's change removing publicKey from ScopedCredentialInfo if you can.
Rolf: is there supposed to be something in the vgb-u2f-attestation branch?
vgb: i'm fighting my git client, will push something up.
alexei_goog: few comments need to
be addressed on the PRs
... such as the question around what if rpId and U2F appId extension are inconsistently specified.
... haven't looked at Jeff's PRs yet, will do right now.
nadalin: some PRs, 16 open issues on WD-03 milestone
gmandyam: question on PRs
... comment on one of the PRs said attestation info wasn't present in getAssertion response
... so no way to include dynamic "attestation" info such as health state in assertions?
vgb: can do it as an extension
similar to UVI or UVM
... attestation info itself is only generated at makeCredential time.
gmandyam: look at platform attestation such as SafetyNet. so if you wanted to get the API safety information again at getAssertion time, you'd want to define a SafetyNet extension. that's fine if that's what the spec says.
alexei_goog: trying to understand where the public key will come from now that it is removed from ScopedCredentialInfo
Rolf: it was always the case that the attestation included it, because it has to be signed over.
there is an echo echo echo
alexei_goog: ScopedCredentialInfo has publicKey now, is the proposal for the pub key to come from authenticatorData?
... section 5.3.3
<JeffH> the credential public key is (and always has been) coveyed in authenticatorData."
<JeffH> attestation data"
<JeffH> see issue #94
alexei_goog: still not convinced
<JeffH> scopedCredInfo.publicKey is not utilized anywhere in the spec (in master branch)
vgb: 5.3.3 will be tweaked for u2f, but every format will have the public key in there
gmandyam: so this is a requirement on attestation formats now
vgb: yes, this will be in my u2f change
alexei_goog: and presumably the format of the key will be specified
vgb: yes, for each format
alexei_goog: about the AAGUID in
there - one purpose of this is to look up metadata
... ideally should be a canonical way to go from AAID (UAF) to AAGUID
<JeffH> simplly regard AAID as a byte string ?
vgb: could just generate random number and check against MDS if you really want to make sure?
alexei_goog: AAID also contained a vendor ID which worked well. can we have a mapping from there to AAGUID?
<apowers> AAID is in the format VVVV#DDDD
<JeffH> simplly regard AAID as a byte string ?
vgb: could we just say AAGUID = SHA256(AAID) for such authenticators?
<apowers> where VVVV is the hex encoding of the Vendor ID and DDDD is four hex bytes for the Device ID
<JeffH> could do that too
<apowers> so technically AAID is 4 bytes
alexei_goog: could do that, but since AAID is so small maybe more potential for collisions?
<JeffH> thety are backed by a registry
<Zakim> weiler, you wanted to tell Jfontana he's been muted. and to announce the PAG, before the top of the hour
<apowers> vgb: it follows the same model as other CE standards -- assigning a namespace to a vendor and then letting them figure out how to assign the numbers in their name space
alexei_goog: still seems icky to
me, but meh
... seems like no strong opinions?
apowers: nice thing about AAID is that it includes a vendor ID so you can ban a vendor completely
alexei_goog: but you could do the same by looking up vendor in MDS based on AAGUID?
apowers: maybe, not sure.
alexei_goog: but MDS may want to maintain one index not three, so may be good to have a deterministic AAID -> AAGUID mapping
<JeffH> i would do most simply conversion of aaid to aaguild and add text to aaguid that impleentors should only generate aaguids that are some fixed length >> 9 bytes
alexei_goog: reason for asking:
when a BT device shows up we want to give user instructions on
how to pair, so we'd like to look that up (maybe in MDS) based
... will make a PR containing some arbitrary-but-logical proposal
<JeffH> vgb: sounds good
Rolf: would like to think through the implications - potential collisions between PNPIDs and USB IDs, and so on
<JeffH> yeah -= so perhaps send such an analysis to the list?
nadalin: putting alexei_goog on the spot about issue #88 :)
alexei_goog: this was mostly a note to self, haven't done anything more
vgb: have been meaning to do that one
nadalin: #123, not sure if we came to a resolution?
<JeffH> i will work on #123 today/tomorow
nadalin: WebCrypto or JWS?
<JeffH> it is assigned to me
vgb: why not JWS? WebCrypto is only advantageous if you allow the full dictionary so it can be more expressive.
Rolf: haven't had cycles to work on it
JeffH: (on IRC) will work today / tomorrow
<JeffH> vgb: thx
gmandyam: would prefer to follow W3C precedent by using WebCrypto (which is W3C) instead of JWS (which is IETF)
<JeffH> we need to figure out whether the data obj in question are JWS or are WebCrypto and then use the correct term.
nadalin: let's try and get these closed as soon as we can so we can do a WD-03 and later a CR
<JeffH> pls review current PRs
nadalin: try and make some progress
vgb: has more time after 21st
Rolf: has more time after 28th
<JeffH> jeffh: has time this week & next
nadalin: people still believe that 27th is doable for WD-03?
Rolf: maybe need 2 weeks more
nadalin: will push it out another
week, and CR correspondingly
<Zakim> weiler, you wanted to announce the PAG, before the top of the hour
nadalin: a PAG has been formed.
some of you may be contacted. that is all.
... see you next week
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found ScribeNick: vgb Inferring Scribes: vgb WARNING: No "Topic:" lines found. Default Present: weiler, gmandyam, rbarnes, nadalin, apowers, Rolf, vgb, alexei-goog, angelo, (on, irc, only), jfontana, Ketan Present: weiler gmandyam rbarnes nadalin apowers Rolf vgb alexei-goog angelo (on irc only) jfontana Ketan Regrets: wseltzer Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2016Oct/0056.html Found Date: 19 Oct 2016 Guessing minutes URL: http://www.w3.org/2016/10/19-webauthn-minutes.html People with action items: WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]